Extensible Markup Language
Part I: Why the Fuss?
Pawan Vora , pvora@uswestmail.net
NexTag.com
Few years ago it was HyperText Markup Language (HTML) that was going to solve the world's interoperability problems. It was touted as the cross-platform language for communicating data and information. And now it is Extensible Markup Language (XML). So is it just a passing fad? I believe not. I believe XML has the potential to live up to the hype and will change the way we design Web pages and Web applications. But I'll let you be the judge. What I'll do is use this column to write a series of workshops on XML explaining what it is, how it can be used, what can be done with it, and what it promises for the future of the Internet. I'll leave it up to you to decide whether XML will have any impact or not.
So let's get started. In this first workshop, I won't talk about what XML is and how it relates to HTML and SGML (Standard Generalized Markup Language) and so forth. Instead I'll focus on explaining why XML makes sense. We will get into the details of writing XML and its relation to other technologies in the next workshop.
Let's take a look at the codes shown in Example 1 and Example 2. Example 1 is the HTML code and Example 2 is a possible XML code of the same information (my explanation later will make it clear why I call it "a possible XML code").
| Example 1: An HTML Document |
|---|
|
<h1>Cyber Rules: Strategies for Excelling at E-Business</h1> <h2>Thomas M. Siebel and Pat House</h2> <h3>1999, New York, NY: Currency/Doubleday</h3> <h3>ISBN: 0-385-49412-2> |
| Example 2: A Comparable XML Document |
|
<book> <title>Cyber Rules: Strategies for Excelling at E-Business</title> <authors>Thomas M. Siebel and Pat House</authors> <publisher year="1999"> New York, NY: Currency/Doubleday </publisher> <isbn code="0-385-49412-2" /> </book> |
| NOTE |
|---|
|
The reason XML and HTML codes look similar is that both are related to SGML (Standard Generalized Markup Language), but in a different way. Technically speaking, XML is a subset of SGML and HTML is an application of SGML. We'll learn about it in Part II of this workshop.
|
So, what's the difference between the two? As you can see, the XML code looks quite similar to the HTML code in that it uses elements in angled brackets (e.g., <book>) and it uses quoted attributes (e.g., code="0-385-49412-2"). What is different, however, is that XML tags attempt to describe the information it contains in those elements. In that sense, XML is what is referred to as " self-describing."
Do you think this self-describing property of XML useful? I hope you answered "yes." To understand its benefits, consider that you had all the books in the world described using the XML tags shown in Example 2. Wouldn't it now be easy for someone to write a program that searches for books using title, author names, publisher, year, and ISBN (quite similar to how you do searches at amazon.com or barnesandnoble.com)? Now compare that with how you search for books at search engines like AltaVista or Lycos or Excite. Try it and see how many hits you get!
Of course, Example 2 is a very simplistic example. I am sure you can come up with ways of describing books using tags that are much better than what I have given above. Could you do that with HTML? Perhaps you could come up with a better way to present the data, but not describe the data, correct?
Let's take a pause and see what benefits we have identified for XML:
- With XML, you are not restricted to a fixed tagset like HTML. One can come up with a tagset that better fits the information they are tagging (i.e., marking up).
- Because you can describe the data in XML, you have much richer data when compared with HTML without marking it up using those META tags (for more information on META tags, see Improving "Searchability" of Your Web Site).
- With XML documents, searching can be made more precise and results more relevant.
Now let's go one step further. Assume that you were running a bookstore and that you regularly received information from a variety of publishers about the new books being published. Now assume that different publishers used their own way to markup the data about the books before sending them to you. Of course, you want to have everything in one database so that you can run a kiosk where your patrons can search for books, you can create your own inventory system, and so forth. To do so, you will need to write a separate program (we can also call them a parser) for each publisher to convert data from their unique format to a format that your database is happy with. Would that be very smart? But, don't you think that's the way we do it on the Web?
Now let's assume that you met with all the publishers (and other bookstore owners) and came up with a standardized way of marking up the data they supply to you and other bookstore owners. Your life is better now! Now you have to write only one parser to convert the publisher's data to store in your database.
Lest you feel we were done, let's be a little more imaginative and consider that all this data was marked up in XML (which could be done in both the situations above, by the way) that you stadardized for them, which was self-describing, and that your database understood XML and was able to take XML data and store it directly without any intervention from you (consider how you take data from Microsoft Excel and put it in Microsoft Access). That's much better, isn't it? Now you don't have to wriet a parser to convert the data to store in your database. If you think this scenario is farfetched, think again. This is exactly the reason why XML is generating so much excitement. Once you have applications that understand XML, your information exchange needs get simplified considerably. Just consider how this will simplify the purchasing process on the Web for e-commerce. How the data you provide about your credit card, shipping information, and so forth can be communicated to clearinghouses and warehouses anywhere in the world for quicker approvals and delivery. (We will talk about XML's implication for e-commerce later.)
So let's summarize and see what more have we learned from above examples?
- XML will be beneficial (and live upto its hype) only if there are industry-specific standards for tagging (i.e., describing) data and that the companies in those industries use those standards for exchanging and communicating information.
- To take advantage of XML, you don't need to present the data on a browser. You can get considerable benefits and cost savings simply by having the information available in a standardized self-describing format.
I hope I have given you enough to think about and have explained to you reasons behind the excitement created by XML. In the next issue, we will get more into what XML is, how it relates to other technologies, how is it different from HTML (syntactically), and how you can write your first XML document. Until then, if you have any questions or suggestions for me, feel free to send me an e-mail to pvora@uswestmail.net. I will try to answer your questions and also post it for other readers in the next issue of Internetworking.
© Internet Technical Group
Last update: August 15, 1999
URL: http://www.sandia.gov/itg/newsletter/jun99/workshop_xml.html
hosted by Sandia National Labs
Disclaimer: Neither Sandia Corporation, the United States Government, nor any agency thereof, nor any of their employees makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately-owned rights. Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise does not necessarily constitute or imply its endorsement, recommendation, or favoring by Sandia Corporation, the United States Government, or any agency thereof. The views and opinions expressed herein do not necessarily state or reflect those of Sandia Corporation, the United States Government or any agency thereof.