Microsoft Corp.’s recent spate of announcements about support for XML in its Office product are just the latest sign that XML is rapidly penetrating every corner of the IT space, even corners which until recently were completely proprietary.
When it started, XML was small and simple, and many people believe that’s why it was so successful. However, XML isn’t standing still, and despite the misgivings of some of its original creators, the standards are getting bigger and more complex all the time.
Although the base XML specification has remained unchanged for nearly five years, a vast superstructure of related standards has been built on top of these foundations. This article tries to give an overview of the landscape, and the specifications you actually need to take notice of.
A layered model
I find it useful to think of the whole structure as having four layers: the XML core; the basic XML toolkit; schema and query; XML Applications.
Layer 1 is the XML Core. The most important part of the XML core is the XML syntax specification itself, which defines the “angle bracket” syntax of XML documents as well as the rather arcane, but still widely used, specifications for Document Type Descriptions. Also in this layer is the XML Namespaces specification, which describes how different organizations using XML can avoid clashes between their different vocabularies, together with the XML Infoset, which is not so much a standard in its own right as a way of modeling the information that XML documents contain.
Coming up soon at this layer are XML 1.1 and XML Namespaces 1.1. As the numbering suggests, these will be fairly small changes to the current specifications, and the new features probably won’t affect many users. It has been said that XML 1.1 is designed to meet the needs of two neglected minorities: Users of the Ethiopic writing system, and users of IBM mainframes.
The changes do affect companies that produce XML parsers. However, there is some risk that during the transition period an enterprise might find itself receiving XML 1.1 documents from one of its business partners before it has upgraded to use an XML 1.1 parser, perhaps even before an XML 1.1 parser is available for a particular computing platform. It can certainly be argued that the people who will benefit from the changes are much fewer in number than those who will have to cope with the disruption that’s caused.
But given that the specifications have been stable for five years, and that the Worldwide Web Consortium (W3C) is trying hard to live up to its name and embrace the needs of all users, it’s hard to complain.
The basic XML toolkit
Layer 2 is what I call the “basic XML toolkit.” I classify these tools as DOM, SAX, XPath, and XSLT. These have all been around for a few years now, and are likely to be familiar to most XML programmers. There are many implementations available, covering all popular platforms, and there’s a good level of interoperability between them, though DOM in particular suffers from having multiple variants and modules within the specification, plus many vendor extensions: Microsoft users are often unaware of when they are using standard DOM features and when they are using Microsoft additions.
XPath and XSLT are currently undergoing a major upgrade to create XPath 2.0 and XSLT 2.0. Although the 1.0 products have been successful, their capability is limited, and users have been waiting a long time for facilities such as the ability to group data by common values, as well as regular expression support. One reason the standards have taken a long time to develop is the influence of XML Schema and XQuery (which I’ll talk about next).
The W3C working groups made the controversial decision to couple the next versions of XSLT and XPath closely to XML Schemas. Because this changes the type system that forms the internal backbone of any programming language. This has required some major re-engineering and it has taken a long time for all the details to be agreed. With luck, though, these specs will be finalized during 2003.
SAX is interesting as a rare example of a standard that was produced by individuals working together without any formal standards organization to support them. Although this worked well to produce the initial versions of the spec, there are signs that doing subsequent upgrades may prove more difficult using this model. However, perhaps this is a good thing, as it will help to prevent the accumulation of complexity that all the other specifications suffer from.
Schema and Query
I sometimes refer to Layer 3 as “XML information management,” because it represents the emergence of XML as a key technology in the way organizations manage their information asset, as distinct from its original role as a syntax for marking up an informal document.
The two main components at this layer are XML Schema, which describes the structure of the information, and XQuery, the query language for accessing XML data. XML Schema has been a standard since May 2001, but it’s a highly complex specification and as yet there are relatively few implementations, and these are incomplete.
Equally complex, and closely related to XML Schema, is XQuery, the proposed specification for querying XML databases, which is designed to play the same role in the XML world as SQL enjoys in the world of relational data. XQuery has been a long time gestating, perhaps because of the sheer number of companies involved in defining it. Although this demonstrates a high level of industry commitment to the specification, designing a language in a large committee is not always a recipe for success.
XML Schema and XQuery have attracted a fair amount of controversy. They are highly complex standards, difficult to understand and difficult to implement, and thus not very accessible to the open-source community that has done so much to make XML layers 1 and 2 usable and affordable, and therefore successful.
XML Schema has even caused something of a rebellion in the form of a competitor, Relax NG, which many people feel achieves the same goals with a vastly simpler architecture. Yet in big organizations, the W3C specifications appear to have widespread support, and there is every sign that they will be widely adopted in time. Microsoft Corp.’s Office announcements in Baltimore underline this: if you want to gain the benefits that XML brings to this product line, you’re going to have to learn to live with XML Schema even if you can’t learn to like it.
XML Applications
Layer 4 is a bundle I will simply call “XML applications.” Of course, one man’s “application” is another man’s “infrastructure” – it all depends whether you look at it from above or below.
In this area I put all the higher-level specifications that make use of XML, such as the standards that underpin Web Services (SOAP, UDDI, WSDL), and the XSL Formatting Objects specification for high-quality XML-based publishing. I would also include the myriad specialist XML vocabularies covering every conceivable area from financial information, business reporting, and news transmission, to specialist vocabularies such as MusicXML for music publishing, and HumanML which describes “human characteristics including physical, cultural, social, kinesic, psychological, and intentional features.”
Other specifications
There are other specifications that don’t fit neatly into this structure, for example the hyperlinking standards XPointer and XLink. In fact, one could argue that one of the reasons these specs haven’t been so widely adopted as some of the others is that they are architectural misfits.
XPointer, which allows one document to contain references to the content of another, has been rewritten several times, and perhaps the current version will attract wider support than its predecessors. XLink, which builds on XPointer to define a model for hyperlinking between documents, still suffers from the fact that no one quite knows how it fits in with the other specifications in the XML family.
Conclusions
IIt has often been said that the great thing about standards is that there are so many to choose from. The XML family is no exception: it’s growing from the original XML 1.0 specification, which was about 40 pages long, to a vast library of documents, many of which run to hundreds of pages.
Layers 1 and 2 in the structure are proving pretty stable and will continue to be the baseline for most XML programmers. The new 2.0 versions of XPath and XSLT will probably catch on because they contain many facilities that are desperately needed to counterbalance the support for XML Schema which quite a few existing users would rather do without.
The new specifications in Layer 3 – XML Schema and XQuery – are likely to be increasingly important as XML becomes central to the IT strategy and architecture of large enterprises. But as the enthusiasm for Microsoft’s recent announcements demonstrates, layer 4 – the applications – is where all the real business benefits come from.
About the Author
Michael Kay is a systems architect working for Darmstadt-based Software AG: He is a member of the XQuery and XSLT working groups, and is well known for his book XSLT Programmers Reference by Wrox Press. Born in Hannover, he is now a teleworker based in Reading, England.
