XQuery -- Reinventing the Wheel?

Date:      Wed, 21 Feb 2001 15:34:48 -0800
From:      Evan Lenz <elenz@xyzfind.com>
To:        xml-dev@lists.xml.org
Subject:   XQuery -- Reinventing the Wheel?

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.

Prepared by Robin Cover for The XML Cover Pages archive. See "XML and Query Languages."

SEARCH Advanced Search ABOUT Site Map CP RSS Channel Contact Us Sponsoring CP About Our Sponsors NEWS Cover Stories Articles & Papers Press Releases CORE STANDARDS XML SGML Schemas XSL/XSLT/XPath XLink XML Query CSS SVG TECHNOLOGY REPORTS XML Applications General Apps Government Apps Academic Apps EVENTS LIBRARY Introductions FAQs Bibliography Technology and Society Semantics Tech Topics Software Related Standards Historic	XQuery -- Reinventing the Wheel? Date: Wed, 21 Feb 2001 15:34:48 -0800 From: Evan Lenz <elenz@xyzfind.com> To: xml-dev@lists.xml.org Subject: XQuery -- Reinventing the Wheel? 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. Prepared by Robin Cover for The XML Cover Pages archive. See "XML and Query Languages."