[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XQuery - The truth comes out!
- From: Jonathan Robie <Jonathan.Robie@SoftwareAG-USA.com>
- To: Evan Lenz <firstname.lastname@example.org>, email@example.com
- Date: Sat, 24 Feb 2001 20:59:18 -0500
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 -
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 -
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 -
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
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
>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
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.
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.