[xsl] XQuery (was Designs for XSLT functions)

["Evan Lenz" <elenz at xyzfind dot com>]

Jeni Tennison wrote:
> > I must admit to being completely confused by XQuery. It seems like
> > reinventing XSLT but without XML syntax for programming constructs
> > (admittedly a fair step to take). I thought that it might be that
> > XQueries are for building XML from things other than XML, but the
> > XPath-like syntax seems to imply that the source (e.g. database) is
> > accessed as a node tree anyway. I feel sure that I must be missing
> > something.

Michael Kay replied:
> I think XQuery and XSLT/XPath are on convergent paths: they are
> tackling the
> same problems, and if each follows its natural course they will
> end up with
> broadly equivalent functionality. But they are coming from different
> traditions, and as a result they currently have different strengths and
> weaknesses, as well as different syntactic appearance.


What a delightfully neutral-sounding paragraph, so matter-of-fact! :)

The question in my mind is: should the W3C recommend two different languages
which provide "broadly equivalent functionality"? And they're not just
equivalent, but they have almost indistinguishable data models and
processing models. 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.

My simplistic analysis is that

XQuery = XSLT - templateRules - nonAbbreviatedXPathAxes


Regarding XQuery and XPath, David Rosenborg wrote:
"In my opinion they have obfuscated XPath. Instead of describing
the XQuery language as an extended subset of XSLT/XPath they went
inventing their own syntax and semantics which are similar but not
compatible with XSLT/XPath."

I completely agree with this sentiment. "Ordered forests" instead of
unordered node-sets, etc. etc. And new extensions that IMHO reflect a lack
of understanding of XPath, such as:

empty($node-set)           instead of    not($node-set)
@mgr->*                    instead of    id(@mgr)
chapter[RANGE 2 TO 5]      instead of    chapter[position() >= 2 and
position() <= 5]


And XQuery's allowance for defining a default namespace for XPath
expressions is pure evil.

And I was hurt by the distinction between "a human-readable query syntax and
an XML-based query syntax".

I could go on (and will at XSLT-UK, but that will hopefully be more than a
mere rant).

The areas where XQuery arguably 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.)

In my opinion, 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 I don't
mean the "abbreviated syntax of XPath," which is basically the extent of the
explanation of XQuery's relationship to XPath.

So, no, Jeni, you're not missing something.

Evan Lenz
XYZFind Corp.


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list