What is the point in XML?

[timmillwood]

I have been set the task in uni to make two sets of static html pages using XSL techniques and multiple XML data source(s).

I cannot see the point in making static HTML pages in XML, the only use for XML I can see is RSS feeds.

If you wanna help, feel free...

 

[epochblue]

The purpose of XML is to be a generic, human-readable markup language that serves as a basis for consumption.

XSL exists to turn one XML doc into another XML doc. For example, take this generic XML, run it through an XSLT and get an HTML page and an RSS feed from it. Or you could use that XSLT to turn it into another XML that some external system might understand, etc.

The crux of XML is that it's nothing and everything at the same time. By itself it isn't much, but it's an excellent, generic format on which you can build any number of things.

 

[GothicChess.Com]

The purpose of XML is to be a generic, human-readable markup language that serves as a basis for consumption.

XSL exists to turn one XML doc into another XML doc. For example, take this generic XML, run it through an XSLT and get an HTML page and an RSS feed from it. Or you could use that XSLT to turn it into another XML that some external system might understand, etc.

The crux of XML is that it's nothing and everything at the same time. By itself it isn't much, but it's an excellent, generic format on which you can build any number of things.

And this differs from HTML in what way?

 

[epochblue]

And this differs from HTML in what way?

HTML is a specific markup language for the web. XHTML tries to bring XML-style formatting and rules to HTML, but HTML is web-specific. The DTDs used to validate HTML documents allow you to only use a specific set of elemtns and attributes. XML has no such restriction. You can create whatever elements/attributes you want.

This thread might help.

 

[mkrishnan]

And this differs from HTML in what way?

Also, the idea of XML is that it stores concepts and information, in a structured fashion, rather than just laid out text. So the big difference between HTML and XML is that XML can deal with conceptual categories and types of information.

 

[dcv]

In very basic terms: think of XML as "portable data" (or rather a way of describing that data). It's essentially just a markup language for describing anything you like. XSL is the effective "stylesheet" language to transform your XML data into something meaningful. It isn't restricted to just the creation of web pages, as HTML is. I've been using XML/XSL for years, for example publishing information from RDBMS and Domino databases into PDF format.

 

[notjustjay]

I like the "everything and nothing" definition of XML. It's definitely getting a lot of hype, some of it undeserved. I have a coworker who thinks it's the next greatest thing to sliced bread, and we use it on our project for all kinds of things including external data representation.

In some ways you can think of HTML as a specific use of the XML format (although this isn't 100% technically accurate).

Suppose you're writing a phone book program that will display a list of names and phone numbers. You want to save the phone list to a file on disk. You've got a couple of options for how to do this:

- One way would be to have C++ or Java just "serialize" the data structure you're using and dump it to a file. You get a binary file that would look like gibberish if you tried to view it in, say, TextEdit.

- Another way would be to dump the info into a text file, say, name followed by phone number, separated by commas. Or pipe symbols (Bob|555-1212). Or on separate lines. Whatever, it's your program.

- A third way would be to define an XML file format, that maybe looks like this:

<phonelist version="1.1">
<entry>
<name>Bob</name>
<number>555-1212</number>
</entry>
</phonelist>

What does that buy you? Well, if you were to open this up in TextEdit, it would make much more sense to you than the binary gibberish or even the plain-text (but proprietery encoding) format. You could edit this file by hand (or with other tools) and your phone book app should still be able to read it. Assuming you make the format rules available, anyone else could make phone book files, so you've suddenly created an open file format. If you can convince other phone book authors to use the same rules, you've got an open standard.

You've got enough code in there that computer algorithms know how to work with or translate the data into other forms. Your rules allow you to validate the data to confirm the phone list isn't corrupted.

Within your program, you can use an XML parsing library and "boom" load or save the data in just a couple of steps, as opposed to writing up whole routines to manually parse some other file format.

But there's no magic to it. It's just a structured way of writing stuff into a text file. So is HTML.

 

[ChrisA]

And this differs from HTML in what way?

HTML is a subset of XML. The HTML subset can define how text is to look and can define forms. But here at work we deal with spacecraft telemetry. HTML is not good at all for specifying the format of the telemetry data but XML is well suited to that job.

At other job we used XML to describe a transaction such as (in our case) the purchase of some metal from a mill. The XML file is what was moved between the buyer's purchasing system and our metals brokerage company.
The neat thing about XML was that we could transform it into HTML so the order could be read by a human or we could transform in into SQL to the Oracle DBMS could be updated or we could transform it into some funky text based records to feed some 30 year old accounting system at a steel mill.

There is more to computing than the web. HTML is only good at web pages. Other XML subsets are good at other things.

 

[timmillwood]

but if you were making a website to list all of the CDs that you own would you do it in XML or a database.

 

[mkrishnan]

but if you were making a website to list all of the CDs that you own would you do it in XML or a database.

You put the CDs in the database, but lots of XML would be flying around in the middleware layer....

 

[epochblue]

You put the CDs in the database, but lots of XML would be flying around in the middleware layer....

Exactly. Store the info in a database, and have something pull the information out of the DB and into an XMl file. Then use the XML to pass the information from the database to something else (a program, a web service, a webpage, whatever).

 

[LtRammstein]

The way I'm starting my website is with the idea of AJAX, XML, PHP, MySQL.

I will have the user input data, and that's sent to the server to be stored, and then whenever the proper PHP function is called, it'll retrieve it and put it in an XML file so that AJAX can display it all pretty-like. I know there's an easier way of doing this, but that requires me to use XSL (which I do not like).

Steve

 

[epochblue]

They way I'm starting my website is with the idea of AJAX, XML, PHP, MySQL.

I will have the user input data, and that's sent to the server to be stored, and then whenever the proper PHP function is called, it'll retrieve it and put it in an XML file so that AJAX and display it all pretty-like. I know there's an easier way of doing this, but that requires me to use XSL (which I do not like).

Steve

Have you considered JSON instead of XML? Depending upon how much data you're sending back, the XML overhead may not be necessary.

 

[SC68Cal]

XML stitches a lot of formats that were previously unrelated, under one umbrella.

OS X plist files, web pages, word documents, itunes playlists, etc... All can be handled by XML