XML and you

September 27, 1999
by Zac Belado

You can't swing an expired IDE drive at your local magazine rack without hitting a glossy publication extolling the virtues of XML. XML is this year's Java. Everyone is writing about it and depopulating whole rainforests with impressive coffee table sized books on the intricacies of XML, but almost no-one is actually talking about the practical aspects of using XML. Or even why you might want to use it.

Be forewarned. This article will discuss XML without actually resorting to any arcane theory and prolonged discussions of the technical aspects of the XML specification. Frankly you don't really need to know any of that...well its certainly nice at some point, but the author is a firm believer in not letting the lack of theoretical knowledge get in the way of using a new technology.

What is it

XML stands for Extensible Markup Language. Which begs the question...what the heck does Extensible Markup Language mean? XML is a meta-markup language. That means that it is a set of rules and syntax used to help describe how to create a language to describe a set of data. XML by itself doesn't describe anything. Unlike HTML or VRML, all XML does is formalize a way of describing a new markup language.

Which is all rather moot as you can do quite a large number of very interesting things using XML without having the slightest idea what you're doing. There are only 4 basic rules that you need to follow to write well formed XML documents.

All tags must have an opening and closing tag.
All tag pairs must be cleanly nested (overlapping elements are not allowed).
All attribute values inside a tag must be enclosed in quotation marks.
Each XML document must have a unique first element, the root node.

An Example

Let's get the ball rolling (so to speak) by describing a set of data for which we would like to create a new markup language.

Imagine that you have a client who wants to be able to share slide presentations among members of their company. Each slide is saved on a remote server (that has web access). The client would like to be able to send a file to a colleague that fully describes a slide show and then be able to view the results of those files either via the web, a CD-ROM presentation or an application.

Since you've been hearing so much about XML you decide to see if you can create an XML markup language to describe the slides and the slide-shows.

Each slide-show will have the following features

A title for the slide show
An author
The author's email
An indeterminate number of slides

Each slide will have the following features

A slide name
A URL to the graphic for the slide
A small description of the slide

Looking back to our list of requirements we see that our XML documents will need a root item (or node) that is unique. Lets call it "slideShow"

So to start our XML document has a single node. We'll call this root node slideShow.

<slideShow>
</slideShow>

This is the root node of our document and all the subsequent details we add will be included inside this node.

Now we need to add the title. Since the title only appears once and has no details attached to it we can safely add the title as an attribute of the slideshow node

<slideShow title="A test slideShow">
</slideShow>

Looking back at our requirements we notice that all attributes must be enclosed in quotation marks. But only attributes need to be enclosed in quotes.

Now we need to add the author's details. In order to make it easier to access the name and email of each author we will make a separate author node and then add a name and email sub-node to it.

<author>
  <name></name>
  <email></email>
</author>

Again, notice that the data inside thename and email tags is not enclosed inside quotes.

And then we need to add an indeterminate number of slides to each slideshow. As with the author details we will add each slide as a sub node of a larger "slides" node. The benefit to this is that it compartmentalizes the data into its own section...and also because the author is the fussy sort of person who likes details like that

<slides>
  <slide></slide>
</slides>

We now need to add a name, URL and description tag for each slide.

<slides>
  <slide>
    <name></name>
    <URL></URL>
    <description></description>
  </slide>
</slides>

And that's all we need. A sample using the format we described might look like so...

<slideShow title="101 uses for a dead meta-language">
<author>
    <name>Zac</name>
    <email>zac / at / director-online.com</email>
</author>
<slides>
    <slide>
      <name>Use #1: stopping doors</name>
      <URL>http://www.someDomain.com/slides/meta/
      slide1.jpg</URL>
      <description>A dead meta-language stopping a 
      door</description>
    </slide>
        
    <slide>
      <name> Use #2: holding down papers</name>
      <URL> http://www.someDomain.com/slides/meta/
      slide2.jpg</URL>
      <description>A dead meta-language holding down 
      papers</description>
    </slide>
        
    <slide>
      <name> Use #3: scaring children</name>
      <URL> http://www.someDomain.com/slides/meta/
      slide3.jpg</URL>
      <description>A dead meta-language scaring 
      children</description>
    </slide>
        
    <slide>
      <name> Use #4: falling out of cupboards</name>
      <URL> http://www.someDomain.com/slides/meta/
      slide4.jpg</URL>
      <description>A dead meta-language falling out of a 
      tall cupboard</description>
    </slide>
        
</slides>
</slideShow>

So why would I use it?

All well and good you say, but why would I want to use it?

1 XML markup languages allow you to write a set of rules that describe an indeterminate amount of data. Once you have your app or project written to parse an XML file that describes two pieces of data, you can then give it a file that describes 200 pieces of data and it will know how to handle the data. Using our example, a slideshow that has 10 slides is parsed in exactly the same way that a slideshow with 110 slides is.

2XML files allow you a degree of cross platform, cross browser and cross application portability that almost no other format does. If you have written an XML markup language you can use that data in a web page, a CD-ROM and an application with no fear of data incompatibilities. XML is unique in that it is a step back in technological terms (it's a text file) but a step forward at the same time because of this flexibility.

3 XML markup languages allow you to "re-use" convenient names without any possibility of confusion. If you look at our example XML markup language you will notice that name is used in two different places. As is title. But this is a safe practice as there is no way to confuse the name tag that is used in a slide node with the name tag that is used in the author node. Each is semantically distinct. Meaning that they each are used in a context that eliminates any possibility of confusion.

4 XML allows you to create an application specific markup language. You no longer need to fit the needs of your application into someone else's data format.

5 XML markup is flexible enough that you can expand the markup languages you make to fit new circumstances, which saves you development time. Perhaps you have another client that wants to also describe slideshows but they also need to add a width and height tag to each slide to describe the dimensions of the slide. Since you have already written code to deal with the first client's slideshow XML format, this new format will be easy to implement since you only need to modify the parsing and display of the code inside a single node...not inside the whole document.

Why will you use it?

XML is one of the more useful technologies to be developed in the last few years. Unlike HTML, XML is inherently well structured. As long as you follow the four simple rules outlined earlier in the article, your XML markup code will be able to be read by an XML parser. XML is also a two-stage process. You use an XML parser to read and store the contents of an XML file but then extract the data as you need it. Once the file is in memory you can use the data far more flexibly than any other type of data.

To continue our slideshow example, we could display the data about a slideshow in different stages. We could initially only display the title of the slide show and the author's name. Then the user could be presented with a list of all the slides and their titles. Then the user could click on a title to see the slide.

All of this is accomplished by reading the XML file once but extracting differing types and amounts of data. Most other solutions would require you to re-read files or re- query data sources to accomplish the same tasks.

As you can see, XML markup is a very effective way to describe and manipulate date inside almost any project you might have. Don't let the theory and mountain range sized books deter you from using what is, at its core, a very simple and flexible tool.

Links and references

Late Night Software has an XML Scripting Addition for those of the AppleScript persuasion.

Microsoft has some interesting (but very MS oriented) content in their XML tutorial. In order to use the interactive sections of the tutorial you will need to be running IE 5.

Andrew White has an exceptional replacement for Macromedia's XML Xtra. It also inludes some useful functions that make working with XML in Director a veritable breeze.

The Annotated XML 1.0 Specification at XML.com.

XML.com also has a set of interesting XML demos.

developer[nation] has a beta version of an RDF/RSS parser built in Shockwave.

Zac Belado is a programmer, web developer and rehabilitated ex-designer based in Vancouver, British Columbia. He currently works as an Application Developer for a Vancouver software company. His primary focus is web applications built using ColdFusion. He has been involved in multimedia and web-based development, producing work for clients such as Levi Straus, Motorola and Adobe Systems. As well, he has written for the Macromedia Users Journal and been a featured speaker at the Macromedia Users Convention.