XQuery -- Reinventing the Wheel?

[Evan Lenz <elenz@xyzfind.com>]

After reviewing the XQuery spec, I'm concluding that the overlap between
XQuery and XSLT is far too great for the W3C to reasonably recommend them
both as separate languages. If XSLT (or XSLT 2.0) isn't considered adequate
as an XML query language by itself, then the development of an XML query
language should still build from the same semantic and syntactic base as
XSLT.

And I think once they come up with an XML syntax, it will be even harder to
look at XQuery with a straight face, with XSLT 1.0 having been published for
well over a year.

What's more is that it seems that the XPath 2.0 and XSLT 2.0 requirements
are trying to fill the gap with regard to whatever slight differences there
currently are between XSLT and XQuery.

Simplistically,

XQuery = XSLT - templateRules - nonAbbreviatedXPathAxes

Apart from datatypes, which XPath currently does not support (but apparently
will), the areas where XQuery purportedly introduces new functionality are
matters of convenience. While possible in XSLT, they are easier to specify
in XQuery. Each of these areas, with a possible exception of the BEFORE and
AFTER operators, are currently addressed in the XPath and/or XSLT 2.0
requirements (grouping, intersection, etc.).

The XQuery spec seems to have little regard for XPath's data model. Instead
of node-sets, there are "ordered forests," and new extensions to XPath
which, IMHO, reflect a lack of understanding of XPath.

XSLT and XQuery, if they don't end up being the same thing, should at least
build from a common semantic and syntactic base, and then adding datatypes,
etc. And I don't mean the "abbreviated syntax of XPath," which is basically
the extent of the explanation of XQuery's relationship to XPath.

To see XQuery "deconstructed", check out:

"XQuery: Reinventing the Wheel?"
http://www.xmlportfolio.com/xquery.html

This paper is adapted from what I'll be presenting at XSLT-UK on "XSLT as a
query language".

Enjoy,

Evan Lenz
XYZFind Corp.