XQuery: The Technology and the Book

I think XQuery is an important book. I'm not wise enough to be sure, though. I'll explain XQuery as a technology and book; you decide for yourself how much applies to you.

You have an XML document (or two, or a few million). You want to retrieve specific information from it (them). How do you do that?

Early in the history of XML, it took programming -- serious programming -- to get anything useful from a document. Initialisms like SAX and DOM represent the best of these approaches. With enough effort, such interfaces made it possible to program XML editors, report-writers, and so on.

Compare to SQL

The relational database world seems to have it better. There, SQL is a single standard that supports many implementations, at least has the reputation of being learnable by non-programmers, and certainly supports interesting optimizations. Wouldn't the XML world make more sense with a "query language" analogous to SQL?

Probably so. Confusingly enough, there are at least three special-purpose languages focused on XML that might fit this description:

• XPath is an "expression language" (as "regular expressions" are). XPath can address the most important elements of XML elements and compute simple results based on them. XPath is easy to learn, and, like REs, is probably most used as an addressing technique embedded in a larger language, like XSLT, DOM, or XQuery.
• XSLT is a functional language that operates on the universe of XML instances, transforming them into other XML documents or occasionally more general reports. XSLT is large, verbose, and relatively mature.
• XQuery is a query language similar in many ways to SQL. It's younger than XSLT and has simpler syntax and semantics, although it is also functional and typed, in a slightly different way. Moreover, XQuery operates on collections of XML documents, not just single instances.

There are a few other languages, like XPointer and SQL/XML, whose use is related to XPath, XSLT, and XQuery, but we'll concentrate on the "big three".

XQuery is a marvelous book. Walmsley is as deeply involved in XML standardization and coding as anyone; at the same time, she writes clearly and sensibly. The combination is rare. While I'm a generally a fussy reviewer who frowns over even such small matters as punctuation, I've found nothing stylistic in XQuery I'd change -- not the sequence of topics, not the way the book transitions from tutorial to reference material, and not the apt selection of examples.

Any developer working with XML can read XQuery. It concisely introduces pertinent independent topics, including XPath, REs, namespaces, XML Schema, URIs, and other names, and query design. I particularly appreciate such "cultural" material as comparisons with SQL and XSLT and the paradigms of push and pull processing. I expect to keep XQuery on my bookshelf for years to come.

Less certain to me, though, is how it will serve others. The difficulty is that XQuery is in the middle of great change. As mentioned above, it's much younger than XSLT, at least in the wide availability of conforming processors. XQuery Update, XQuery 1.1, XQuery Scripting, and XQuery Full-Text are significant enhancements and extensions to XQuery that promise to expand the language's power a great deal.

Conclusion?

I don't understand XML well enough to know what the outcome will be. As things stand now, serious XML processing is typically done in a rather volatile medley of XSLT, XPath, host-language libraries like JAXP and XQJ, and external scripting. When will the important XQuery extensions begin to appear in production systems? Will their availability significantly reduce the importance of XSLT, or change the uses of XQuery 1.0? It seems possible to me our use of XQuery might be much different in a year than it is now; I simply can't predict how good a guide XQuery will be at that time to XQuery best practices.

For now, though, this book is the best and most current single introduction and reference to XQuery 1.0 as we know it in 2007. I'm wary about reliance on XQuery to make technology decisions; if you've already chosen XQuery as an expressive form, though, be sure you have XQuery so you can make the best of it.