Now that you know the basics, this article explains how to use XML's more advanced constructs to author complex XML documents. Entities, namespaces, CDATA blocks, processing instructions - they're all in here, together with aliens, idiots, secret agents and buried treasure.
You've already seen how XML allows you to use descriptive tags to mark up text in a document. These tags are usually free-form; a document author has complete freedom to name these tags anything he or she desires. And while this flexibility is one of the reasons for XML's popularity, it's a double-edged sword, because it begs the question: what happens if tag names in different documents clash with each other?
An example might help to make this clearer. Let's suppose that I decided to encode my stock portfolio as an XML document. Here's what it might look like:
And now let's suppose that Tom, my next-door neighbour and the proud owner of
his own computer store, hears about XML, gets really excited, and assigns some of his employees to the task of encoding his store's inventory into XML. Here's what his XML document might look like:
Finally, let's suppose that Tom and I get together for a drink, tell each other
about our XML experiments and (in a moment of tequila-induced clarity) decide to put XML's capabilities to the test by combining our two documents into one. However, since both documents include a tag named
whose meaning is entirely dependent on its context, it's pretty obvious that
our attempt at integration will fail, since an XML application would have no way of telling whether the data enclosed between <stock>...</stock> tags belonged to my portfolio or Tom's inventory.
It's precisely to avoid this kind of ambiguity that the XML specification now provides for namespaces. Namespaces are a way to uniquely identify specific elements within an XML document. This is accomplished by assigning a unique prefix to an element, thereby immediately associating it with a particular data universe and eliminating ambiguity.
This article copyright Melonfire 2001. All rights reserved.