Re: XQuery - The truth comes out!

[Evan Lenz <elenz@xyzfind.com>]

Hi Jonathan,

On Sat, 24 Feb 2001, Jonathan Robie wrote:
>At 03:20 PM 2/24/2001 -0800, Evan Lenz wrote:
> >Take the following observations, each of which either has been
> >demonstrated by Joe English or me on this list, or has been proclaimed 
> >as the official position of the W3C XML Query and XSL WGs:
> 
> Well, by my tally you quote yourself three times and quote Joe English 
> once, coming to different conclusions than I believe Joe would for his 
> quote. I don't know which official positions you feel you have heard
> from either Working Group, I certainly hope that you are aware none have
> been expressed on XML-Dev during this discussion.

I'm sorry if this statement was misleading. What I should have said is
#1-3 have been demonstrated on this list. #4 is an offical position of the
XML Query and XSL WGs. And, yes, I recognize that you and others from the
WG that might be participating in this discussion are expressing their own
opinions and not necessarily those of the WG.

> 
> >1. Template rules are a sophisticated form of syntax sugar and can be
> >expressed as an XQuery function -
> >http://lists.xml.org/archives/xml-dev/200102/msg00585.html
> 
> Well, yes, you said this. But do you know the difference between syntactic 
> sugar and a processing model? The fact that a recursive XQuery function 
> that iterates over all the nodes in a document can compute the same result 
> as XSLT templates does not mean that an XQuery implementation is going to 
> be optimized for that, or that the two languages use the same processing 
> model. The clearly do not. Or do you believe that Lisp and SQL have the 
> same processing model?

It's not about computing the same results. It's about *expressing the same
meaning*. Two queries that express the same meaning will, of course,
always compute the same results. And, of course, there are many queries
which express different meanings, use a different processing model, etc.,
but only *happen* to compute the same result. My assertion regarding #1 
(as well as #2), is that there are equivalent XQuery queries that not
only compute the same results, but express the same meaning. What I mean
by "express the same meaning" could probably be defined as 
"algorithmically convertible from one to the other at compile-time". All
the arguments I've heard about the optimization problems of XSLT are
regarding compile-time analysis. If there is an equivalent (same meaning)
XQuery for every XSLT stylesheet, then this argument does not hold much
water.

Of course, I make a bigger claim as well, that not only is virtually any
XSLT query algorithmically convertible to XQuery at compile-time, but that
many of them, in particular those that only use "down-reference pull" are
not only trivial to convert, but the conversion is obvious to the user.

An example may be helpful. A series of IF THEN statements in a
recursive FUNCTION definition certainly does not look like the same sort
of thing as a set of template rules. This conversion, though determinate,
is not obvious to the user. Likewise, but to a lesser extent, the
conversion of ancestor::foo to a recursive ancestor() FUNCTION definition
a la Joe English's demonstration, is not an obvious conversion either. But
the conversion of xsl:for-each, xsl:variable, xsl:copy-of, etc. is not
only algorithmically convertible to an equivalent XQuery query, but that
conversion is also obvious to the user. These queries not only have the
same meaning with respect to my definition of "same meaning" above, but
they also have the same meaning with respect to syntax appearance, etc.
This, of course, uses a more subjective and relative definition of "same
meaning", insofar as not all users are the same.

The exclusion of template rules and the other XPath axes from XQuery would 
provide a deterrent from expressing certain kinds of queries, but not a
preclusion from the possibility of expressing those kinds of queries, even
if the language is not particularly optimized for them. That's the primary
point I'm making, and that's why I called it a "sophisticated form of
syntax sugar".

> 
> >3. XSLT 1.1 introduces composability by making arbitrarily constructed
> >trees first-class citizens -
> >http://lists.xml.org/archives/xml-dev/200102/msg00587.html
> 
> Well, I think this demonstrates that you did not understand what Michael 
> Rys meant by compositionality.

My understanding is that compositionality, or composability, refers to the
central importance of *expressions* and that expressions can be composed
into other expressions, which can in turn be composed into other  
expressions, etc. Michael Rys correctly pointed out that there is an issue
of syntax with regard to XSLT's being made composable. Whereas in XQuery
you may simply put parentheses around a FLWR expression and access it as
an expression, in XSLT 1.1 you have to basically give the expression a
name (using xsl:variable) before you can syntactically use it. I don't
believe the important thing about composability is how many characters you
have to wrap around what's considered to be an expression, but rather what
objects you can and can't access as an expression. Is this not a correct
understanding?

I don't presume to know what Joe English's conclusions are, but he also
made this observation, in a separate post: 
http://lists.xml.org/archives/xml-dev/200102/msg00519.html

> 
> Or does your statement about subsets mean that they should share a common 
> expression language, XPath 2.0, as we are already doing? If so, I agree 
> with you.

No, I think that the subset used by XSLT and XQuery (assuming one must
have features the other doesn't have) should extend beyond the path
expression language (which will have the same syntax) into the result
construction language (which may have different syntaxes). This result
construction language, the flow control, the iteration, the conditional
statements--these should all have the same meaning and should be defined
in terms of each other. I haven't yet seen a good reason why they should
not.

XSLT currently lacks a bunch of XQuery features, yet these are almost
entirely related to XML Schema datatypes. The XSLT 2.0 and XPath 2.0
requirements working drafts indicate that XSLT will support these
datatypes as well, thus closing that particular gap. I am happy that 
XPath 2.0 will be common to XSLT and XQuery. I think this is a good
good thing, but it just doesn't go far enough. Despite the sometimes
alarmist ring to my postings, I have hope that the commonality will in
fact go further, as issues between the two WGs are resolved with regard to
their common use of XPath 2.0. I think a good deal of XQuery's subtle
differences from XSLT lie in the fact that the semantics of its path
expression language are decidedly different from those of XPath 1.0.
Once XQuery and XSLT share a common path expression language, the reasons
for defining at least most of the rest of the two languages in the same
terms will be even more compelling. In this scenario, XSLT's syntax, or a
large portion of XSLT's syntax (such as what can go in one template rule),
could be used as the XML syntax for XQuery. This syntax could be used, as
long as it *means* the same thing as the XQuery "human-readable" syntax.

> 
> >All of the work done by the Query WG on algebra and query optimization can
> >be leveraged and applied to XSLT as well as XQuery.
> 
> Certainly much of it can be - but I thought you were taking us to task for 
> creating our own algebra and data model. Are you now suggesting that XSLT 
> should be defined in terms of the Query algebra?

By the "work done" on the XML Query algebra, which is still a working
draft, I mean to indicate the research and the query optimization
principles that have been learned and are being learned. Insofar as the
algebra was created without considering the semantics of XSLT, which has
the same basic requirements as a query language, I indeed would
be critical. But I don't presume to know to what extent XSLT was
"consulted". What I'm saying is that if XQuery is any representation of
that algebra, then it turns out that, whether XSLT was consulted or not,
it came darn close to the semantics of XSLT and what XSLT (1.1, 2.0) is
becoming. To that extent, there should be no reason why these principles
can't be utilized in XSLT implementations over large data sets.

> Evan, I am impressed by the instantaneous nature of your conclusions

Apart from a summary of what I am learning in this debate, and a slightly
modified restatement of my original opinions, my posting didn't contain
much new. The provocative nature of my subject line was mostly to get a
rise out of you, Jonathan -- jk ;-)

Best regards,
Evan