Quilt Has Querying Covered

June 13, 2000

Edd Dumbill

Jonathan Robie of Software AG kicked off the session on XML Query languages Tuesday afternoon with a description of the Quilt language, of which he is one of the authors.

Defining a query language as a transformation from one instance of the XML query data model to another, Robie noted that none of the current query mechanisms sufficiently covered all the possible applications of XML. For instance, documents have XQL, XPath, and XSLT, relational data has SQL, object data OQL, and semi-structured data XML-QL. All these languages, while insufficient as universal query languages, proved to be a significant influence on Quilt.

As well as having multiple applications, XML also takes multiple forms. Although heavily involved with the DOM work at the W3C, Robie noted that the DOM was only one kind of data source suitable for querying. An XML query language should cover many varieties of XML inputs, including SAX streams, data from DBMS, Java objects, etc. This is achieved by the query language operating on an independent data model, for which there are then translators for each of the possible input and output formats.

One obvious question concerns the relationship between Robie's work and that of the W3C's XML Query working group. At WWW9 earlier this year, the XML Query working group outlined the work they were doing: creating an abstract data model, an algebra to operate on that model, and, finally, a language that can be implemented. Robie and his co-authors (Don Chamberlin from IBM, heavily involved in SQL; and Daniela Florescu from INRIA, who has an object-database background) instead preferred to work with a concrete language that could be compared against use cases. The W3C work is in too early a stage to say whether Quilt may eventually be the choice of the working group, but Robie believed it met all the W3C's use cases for an XML query language.

Under the Covers

Robie explained that Quilt was so named because of its manner of construction. The Quilt authors drew from many sources, imposed one design, used the pieces that fit, and trimmed each piece to the desired shape. Their design goals included the consideration that queries can happen anywhere -- it should not be left to a large server product to conduct the query. Queries could happen in programming libraries, traditional databases, native XML repositories, or editors. Therefore, a simple model for query optimization is also required in order that it be practical for querying capability to be widespread.

The Quilt syntax itself is reminiscent of a combination of BASIC, SQL, and XPath. Robie cited readability and learnability as the reasons for not using an XML syntax for the query. Here's an example:

FOR $b IN //book

   WHERE exists($b/title)

   AND NOT exists($b/author)

   RETURN $b/title

This syntax is not so far away from what developers are used to understanding: Robie reports that people seem to find Quilt easy to learn. Results are returned as XML (or, rather, the query data model representation of the XML). As well as returning plain results, Quilt allows transformations to be performed as part of a query. This is achieved in a manner similar to XSLT -- you can just wrap tags around the query. Anything that is not an element is interpreted as Quilt code.

One particularly interesting feature is the use of XPath and XSLT-like functions. The document() function allows joins to be performed across multiple documents and sources, even different web servers.

First Impressions

Quilt builds on significant experience from the relational, document, and object querying worlds. My initial impression is that it will prove to be very influential on the W3C's query language activity. Given that Quilt exists now, and that the W3C group is just getting going and may not deliver for a while, it looks like we could see Quilt in XML products in the interim.