With a posting titled XQuery -- Reinventing the Wheel?, Evan Lenz has sparked a discussion on xml-dev regarding what he describes as a "tremendous amount of overlap in the functionality provided by XQuery and that provided by XSLT".

Fatdog have released XML Query Engine v0.99, which implements the W3C's XML Query language.

OJXQI is a Java API for XQuery proposed by Oracle. This page introduces OJXQI, and explains the various extensions that Oracle supports inside the XQuery expression for connecting to the database and for binding values etc..

This is a presentation that was delivered at Extreme Markup 2002. The presentation is an introductory tutorial on the use of the JavaCC and JJTree parser-generating tools to build a parse tree representing an XPath or XQuery query.

Early in its history, the XML Query Working Group confronted the question of whether XML is sufficiently different from other data formats to require a query language of its own. The SQL language is a very well established standard for retrieving information from relational databases and has recently been enhanced with new facilities called "structured types" that support nested structures similar to the nesting of elements in XML. If SQL could be further extended to meet XML query requirements, developers could leverage their considerable investment in SQL implementations, and users could apply the features of these robust and mature systems to their XML databases without learning a completely new language.

Despite disharmony among database vendors over web services workflow (or choreography), they do agree on XQuery, the proposed standard for querying XML data and documents.

The IPSI XQuery Demonstrator (IPSI-XQ) is a prototype of an XQuery engine. It is implemented "by the book", that means it is implemented as faithfully as possible along the current W3C working drafts. So it implements the XQuery surface syntax[1], the XQuery datamodel [4], the XQuery functions and operators [5], the mapping to the Core Language, the static type checking and result type inference, the dynamic type checking and evaluation [3]. Additionally it implements an experimental arithmetic optimization module.

The NIST XQuery test suite covers the majority of the functions and operators("fn" and "op" namespaces) defined in the W3C XQuery 1.0 and XPath 2.0 Functions and Operators Working Draft. There is a total of 1880 tests in this release, which are summarized in report.html. This report is included in the distribution under the "files" directory. Functions and operators coverage in this release are summarized in here. Work is underway to merge this testing project with the W3C XQuery working group testing efforts, and we expect this test suite to be a major component of the official W3C test suite.

While XQuery is usually considered an inappropriate tool for querying RDF collections or Topic Maps, Jonathan Robie demonstrated at XML 2001 that using XQuery functions over their normalized forms can be practical and not especially complex.

There’s a lot of interest out there about exposing XQuery 1.0 / XPath 1.0 / XPath 2.0 in Web interfaces. On the face of it, this is quite a compelling idea; it allows you to reuse a generic query mechanism (goodness) to access arbitrary data based on the client’s needs (more goodness) and only the bits of data that you want go across the wire (yet more goodness).

Experimental support for W3C XQuery is available in Fatdog's XML Query Engine 1.0, and Software AG have released QuiP, an W3C XQuery prototype implementation.

The XQuery/XSLT working group released another set of Working Drafts on August 22, 2003. This article is my attempt to summarize the significant changes in the new drafts. Note that there is no new version of either the Data Model or Functions and Operators specifications, which were released to Last Call in May.

At XML Europe, W3C XML Query working group member Jonathan Robie gave a report on the family of specifications. This follows up on a flurry of recent specifications updates from the group, and from the XSL working group.

The XQuery formalization is an ongoing effort of the W3C XML Query working group to define a precise formal semantics for XQuery. This paper briefly introduces the current state of the formalization and discusses some of the more demanding remaining challenges in formally describing an expressive query language for XML.

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

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.

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.