Columns

Is XQuery an omni-tool?

• By Uche Ogbuji
• May 1, 2003

We’ve all seen those commercials for some magic omni-tool that can screw, sand, carve and sharpen assorted objects, as well as remove stubborn grass stains. Most builders would scoff at the idea of replacing all of their specialized implements with an omni-tool, but is XML a different story? After all, with XQuery approaching recommendation status, one could argue that XML is about to get its very own omni-tool.

XQuery can be a simple XML node access language, largely XPath 1.0 with tweaks and more core functions. It offers SQL-like primitives to process large XML data sets, and is a strongly typed system that offers static and dynamic typing (controversial features I’ve noted in the past). It also has primitives for generating output XML (the lack of separation of input and output facilities is questionable). XQuery does not yet allow XML database updating, but update language proposals are under consideration, and XQuery should soon add them.

XQuery is a very important development for several reasons. For one, it comes with a very sophisticated formal model and semantics developed by some of the finest minds in the business. This may seem to be the least-functional attachment to the tool, but it is actually like the oil that keeps the motor from seizing. Given the formal model, a lot of questions about the effectiveness and operation of queries can be answered deterministically. This is important for consistent implementations and advanced techniques.

The data model of XQuery is designed to be friendly to optimizers, which should allow for fast implementations. For users of W3C XML Schema Language, XQuery provides a very rich interface to the Post Schema Validation Infoset. XQuery syntax builds on the XPath expression language and adds a few SQL-like primitives. There is also an experimental XML-based syntax for the language, but it has been put aside for the moment.

But in covering so many bases, XQuery attempts to set an overall standard for an XML processing model and mechanism prematurely. With its sprawling and ambitious requirements/use cases, XQuery claims territory in almost every task typical for developers using XML.

People are already calling the XQuery data model the XML data model. They point to how vendors rallying behind SQL made relational DBMS valuable to the mainstream. The problem with this comparison is that SQL is not an omni-tool; it is designed to work on very highly normalized data sets. XML, by contrast, derives much of its power from denormalization; as a result, there is no way to have a single catchall data model for XML that is suitable for all purposes.

The XML community is surveying the many data bindings and APIs available for XML processing. One clear theme of this discussion has been that users have radically different needs in processing XML documents. Discussions of next-gen XML processing center on the particular strengths of the host language or environment. .NET has evolved processing tools ideal for users of Microsoft’s development tools. Perl 6 brings sophisticated XML capabilities that take advantage of innovations in that language. The same level of innovation is at work in the Java and Python communities, among Flash users, as well as those on embedded and wireless devices.

This diversity of XML processing systems, bound together by XML 1.0 syntax, is a step in the right direction. Rather than catchall SAX, DOM and even XSLT models that cut across the spectrum of XML developers, XML will become a natural accessory for each environment. XQuery represents a counter to this trend. XQuery is not a standardization of mature technology, but the result of a research project by the W3C for designing an XML processing system from scratch.

Just as the community is crafting a great diversity of well-specialized XML processing tools, along comes the XQuery omni-tool, which is complex enough that it is probably not very accessible to the weekend handyman, and yet probably not finely tuned enough to displace the box of professional crafting tools.

Despite this, XQuery has a formalism of thinking about XML processing that can be selectively adopted by specialized tools. The danger is that too many will associate XQuery too closely as the heart of XML processing, obscuring superior solutions for each case.

To read more columns by Uche Ogbuji, click here.