Re: XQuery - The truth comes out!

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

At 08:33 PM 2/24/2001 -0800, Evan Lenz wrote:
>On Sat, 24 Feb 2001, Jonathan Robie wrote:
> >At 03:20 PM 2/24/2001 -0800, Evan Lenz wrote:
>
> > >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?
>
>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.

[ !! SNIP !! ]

>  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".  [ !! SNIP !!] If there is an equivalent (same meaning)
>XQuery for every XSLT stylesheet, then this argument does not hold much
>water.

This reformulation is helpful for me - I think I understand better what you 
are saying. I think that XSLT and XQuery can and should share:

1. A common data model
2. An algebra that defines operations on that model, and which defines the 
static type of the result (as far as possible).
3. A common path expression language - basically the stuff that is in XPath 
1.0.

I do not think that XQuery should attempt to do everything XSLT does and in 
the same way. Even if XSLT is algorithmically convertible to XQuery and 
vice versa (which may or may not be true, we haven't worked through all the 
details, and that would take some time), we still might not know the 
algorithms to do this for all cases, or we might not know algorithms that 
produce a result that would execute efficiently, or we might know the best 
available algorithms and still find that the resulting queries are slow 
simply because XSLT is optimized for template processing and XQuery 
implementations probably will not be.

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

Many of them are. Many of them are not. An exercise for the reader: take 
Norm Walsh's DOCBOOK stylesheet in XSLT, rewrite it in XQuery, and write a 
Python script that can automate this conversion. We can then try applying 
that to some other stylesheets and see how well it works. Look, we're 
trying to define a query language, we are not trying to replace XSLT. If we 
require ourselves to take on this task, we'll never finish our query 
language. This is not the problem we need to solve.

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

XQuery is not that large a language. There is a lot of interest in making 
our XML construction look just like XML. The XPath 2.0 requirements 
(http://www.w3.org/TR/xpath20req) hint that some of what XQuery does now 
could be taken up into XPath, if we can find a good way to do this that 
works for both languages. How much? Well, that depends on a lot of answers 
to a lot of questions we are just now starting to ask.

>The provocative nature of my subject line was mostly to get a
>rise out of you, Jonathan -- jk ;-)

Well, I think you succeeded. But I wonder if we are really saying anything 
new in the last few emails. Are we reaching the point that both of our 
positions are clear?

Jonathan