Re: XQuery - The truth comes out!

[Jonathan Robie <Jonathan.Robie@SoftwareAG-USA.com>]

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.

>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?

>2. The non-abbreviated XPath axes are a sophisticated form of syntax sugar
>and can be expressed as XQuery functions using the parent axis -
>http://lists.xml.org/archives/xml-dev/200102/msg00604.html

Again, I think you are using the phrase syntactic sugar in a very strange 
way. The two languages can compute the same result.

>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.

>4. XPath 2.0 introduces W3C XML Schema datatyping, and will be used by
>both XSLT 2.0 and XQuery - http://www.w3.org/TR/xpath20req

A true statement!

>I'm sorry, but there is little else that's left. Even if we grant that the
>parent axis may be taken away from XQuery (so that the theoretical
>argument that XSLT is inherently harder to optimize might hold *some*
>water), these languages should be defined in terms of each other
>(subsets).

Hmmm....so by your reasoning, if Lisp and C++ can compute the same results, 
they should be defined in terms of each other?

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.

>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?

>There was worry about
>whether it would be possible to retrofit XSLT for formal semantics. The
>intermediate result of the WG shows that this should not be an impossible
>task.

Evan, I am impressed by the instantaneous nature of your conclusions, but I 
find it hard to follow your thinking. Of course XSLT can be given formal 
semantics. In fact, there have been formal semantics for XPath 1.0 for a 
long time - Phil Wadler did them when he was on the XSLT Working Group. 
Which intermediate result of what Working Group shows what?

 > In any case, why should XQuery be optimizable and not XSLT?

If I ever implement a system that uses XSLT to do queries over large 
repositories, I'm going to need a lot more information on optimization 
strategies than "why shouldn't XSLT be optimizable?" If you have useful 
information on this topic, please feel free to share it.

Jonathan


These are my opinions right now. They may be quite different from the 
opinions of Software AG, the W3C XML Query Working Group, or the opinions 
that I will have after reading and considering your response.