This topic describes XQuery and how Liquid Data implements the XQuery standard. It contains the following sections.

Most people think of XQuery as a query language for processing XML "databases". But it is also a very nice language for generating XML and HTML, including web pages. In this article we will look at XQuery from this angle.

XQuery is a query language for real and virtual XML documents and collections of these documents. Its development began in the second half of 1999. With roughly 3 years of work completed, it’s high time that we provided an initial description of this language, and a sense of where it is in its development cycle. XQuery is being developed within W3C.

Howard Katz introduces the W3C's XQuery specification, currently winding its way toward Recommendation status. The complex specification currently consists of 12 separate working drafts (and may still be growing). This article provides some background history, a road map into the documentation, and an overview of some of the technical issues involved in the specification. A sidebar takes a quick look at some key features of XQuery's surface syntax. Code samples demonstrate the difference between XQuery and XQueryX and show examples of the surface syntax.

In a session at XML DevCon 2001 in New York, XQuery working group members Jonathan Robie (Software AG), Michael Rys (Microsoft), Peter Fankhauser (GMD-IPSI), and Jérôme Siméon (Bell Labs) unveiled prototype implementations of the XQuery language. All four concluded that XQuery was relatively easy to implement, with work on three of the prototypes being started in November and finished by January.

Mike Kay from Software AG gave a high level comparison between XSLT and XQuery at the fourth Forum XML, where he concluded that the main differences between the two languages were differences of culture and perspective, but also that XQuery was more ambitious than XSLT and would require more complex optimizations.

This document proposes a query language syntax for XML documents, called ZQuery. Such a query language has quite different requirements than traditional languages; much more different than is commonly appreciated. Many past proposals have taken a basically relational query language (typically SQL), and modified it by the addition of a few constructs: typically a "contains" operator and some features for matching strings within text chunks against regexes, or against word-roots. Such features, while needed, are not enough. The hard problem arises because the most basic design principles of relational databses, do not hold for XML documents.

I'll use Adam Bosworth's keynote at XML 2003 to kick off some thoughts around Xquery and the web. It seems like an interesting world where a service provider could describe their data model and then allow arbitrary queries against it. The current model of both the Web and Web services is that a service provider needs to provide pre-defined operations for each type of query. In fact, this separation of the private and more general query mechanism from the public facing constrained operations is the essence of the movement we made years ago to 3 tier architectures. SQL didn't allow us to constrain the queries (subset of the data model, subset of the data, authorization) so we had to create another tier to do this.

XML Query Language will soon become the "SQL for XML." Be prepared for the next version of Microsoft SQL Server by using a preview of the Microsoft.Xml.XQuery classes.

This download is a prototype implementation of the evolving XQuery language, with Oracle extensions. The release version is RELEASE_0.2_030217. This is a technical preview release.

XQuery 1.0 is not scoped to have any update functionality. I've seen proposals for what might go in after 1.0 and they look reasonable and elegant. In the meanwhile what you'll see is custom vendor functions to handle the job. Cerisent for example has functions for inserting and deleting nodes and documents, and these functions work against path expressions nicely. It's really amazing what you can do when you can generate XML that you feed back into the database as input for later queries.

The following statements are the patent disclosures and license commitments associated with the XML-Query family of specifications and provided by members of the XML-Query Working Group as well as other W3C members.

XML blurs the distinctions between databases, documents, and messages, but it needs a powerful and elegant query language to reach its full potential. XPath does not go far enough. XQuery intends to be that language.

There is a tremendous amount of overlap in the functionality provided by XQuery, the newly drafted XML query language published by the W3C, and that provided by XSLT. The recommendation of two separate languages, one for XML query and one for XML transformations, if they don't have some sort of common base, may cause confusion as to which language should be used for various applications. Despite certain limitations, XSLT as it currently stands may function well as an XML query language. In any case, the development of an XML query language should be informed by XSLT.

A query language for XML based on Xquery 1.0

XQuery is a highly malleable amalgam of an SQL-like syntax grafted on to XPath. At its simplest, an XQuery expression that will likely look familiar is this:

This document is intended to provide an easily readable description of the XQuery XML Query language, and is oriented towards quickly understanding how to create queries. The normative description is mostly provided in the following W3C Working Drafts [*MOS]:

XQuery has some new possibilities, from atomization to trace to file structures.

Query may cause one of the biggest changes to server-side programming since Java servlets. XQuery is a query language specification under development by the World Wide Web Consortium (W3C) that's designed to query collections of XML data—not just XML files, but anything that can appear as XML, including relational databases.

Qexo is a partial implementation of the XML Query language. It achieves high performance because a query is compiled down to Java bytecodes using the Kawa framework. Kawa also includes a proof-of-concept implementation of XSLT.