Re: Why not reinvent the wheel?

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

At 09:51 PM 2/22/2001 -0500, Charles Reitzel wrote:

>One objection is that us poor developers can only squeeze so many syntaxes
>into our heads (at one time anyway).  Subtle differences in processing will
>only cause grief when debugging complex programs. They both have
>if-then-else and for loops.  For better or worse, they are both programming
>languages - and similar ones at that.  Better to get it right once.

And then he wrote:

 > Yes, it is a bit easier to read the FORTRAN-like syntax. If syntax sugar is
 > the compelling argument here, why not develop an XSLT generator?  I am
 > encouraged by coordination around XPath 2.0.  Why not go the rest of the
 > way: just make XSLT the XML syntax for XML Query?

Given the second quote, I assume that Charles agrees that it is easier to 
read and write XQuery (which has variously been called XSLT-like, 
Java-like, FORTRAN-like, and SQL-like!). There probably *will* be XSLT 
generators for XQuery. It may make sense to have a group of people get 
together and define a mapping from XQuery to XSLT.

The mapping in the other direction probably makes less sense. XSLT has a 
number of constructs, such as templates and match patterns, that do not map 
directly onto anything in XQuery, and I do not see a need for them in 
XQuery. We are trying to keep XQuery as small as we can while still meeting 
our requirements.

There is hefty debate about just exactly what the XML syntax for XML Query 
should do. Should it be a syntax for humans to author XQuery in? Should it 
represent the abstract syntax parse tree? Should it be a representation of 
the XML Query Algebra representation of a query? Since XML is just a way of 
representing information, I don't think that there has to be one and only 
one answer to this question. Clearly, an equivalent XSLT stylesheet can be 
one way of representing an XML Query, but it will be semantically different 
from the original XQuery because of differences between the two languages.

>Second, we are not talking about a commercial product, but a standards
>process.  This fragmentation in the standards space will dilute commercial
>support so that it will take longer before we get decent implementations of
>any query language.  Competing standards actually delay or prevent
>competition among products.   Ask any Unix vendor.  Ask Microsoft.  Too many
>standards also weeds out small players.  Only the big boys can support 
>them all.

I'm confused. You seem to be suggesting that we should not develop both 
XQuery and XSLT because we might not get decent implementations of either. 
I thought there were already quite a few implementations of XSLT, and that 
certainly includes some good ones. It is quite easy to embed these in your 
web environment. What exactly are your fears with regard to XSLT support?

As for XQuery support, if nobody decided to implement the language, it 
would die, and our discussion on this list would be moot. I am encouraged 
by the fact that several universities and companies are already working on 
XQuery implementations, and I have seen several demos of prototypes.

Arnaud Saquehet's implementation is fairly complete, though not completely 
compatible, and it is open source:

http://db.cis.upenn.edu/Kweelt/

I can't name names because I don't know exactly who is saying what in 
public. But I'm quite confident that XQuery will be implemented.


Also, would you say that the W3C should not have supported both CSS and 
XSL? What differences do you see between that situation and this one?


I think it is a given that some people will never see a reason for XQuery, 
since XSLT exists. There is a sizable community of people who do see a 
reason for XQuery. I remember when people were really confused about why 
XSLT was needed. I remember long discussions in the SGML community about 
whether there was a need for XML. Object orientation was invented in 1967, 
but object orientation was not mainstream until the late 1980s. New 
technologies take time to understand and appreciate. Of course, hogwash 
takes time to recognize and discard.

>Jonathan Robie keeps saying that the XML Query use cases are different than
>XSLT.  But there have been numerous protests to the contrary on this list.
>Perhaps he could tell us which of the XML Query use cases cannot be applied
>to XSLT?

I never said "cannot be applied". Since XSLT is Turing complete, it would 
be wrong to say that the use cases cannot be applied to XSLT. It is just a 
lot harder to do so. In fact, quite experienced XSLT programmers have sent 
me wrong solutions to some of the use cases, and we've had long discussions 
before we could agree that the proposed solution was wrong.

Take a look at Evan's paper. Even some of his examples show things that I 
find significantly less straightforward in XSLT.

You say that there have been protests on this list, and therefore I should 
work up a list of the use cases that cannot be applied and defined it here. 
My obvious worry is that this would be an infinite time swamp. Nobody has 
yet provided a complete set of solutions to the use cases in XSLT. Several 
people have started. Evan has solved a few for which I had not previously 
seen solutions. I would be very interested in seeing a complete set of use 
cases, but I'm not willing to spend the time to create them.

>I am not buying the optimization argument either.  By exposing random access
>XPath (pointed out by Joe English), there is effectively no difference
>between them.

Random access XPath? I think that Joe English pointed out that we allow the 
parent operator in XPath. I think that's a long ways from saying there is 
no difference between XSLT and XQuery for query optimization.

>My personal opinion, is that a standard schema would provide
>a stable footing that allows work to go ahead on static analysis of document
>bases.  This document analysis will drive query optimization (as pointed out
>by others on the list).  Ordering and equality rules for datatypes will
>assist this effort!

This is all true, assuming you mean "a common approach" when you say "a 
standard schema". The XPath 2.0 effort goes beyond sharing syntax. Both XSL 
and XML Query would benefit by good static analysis of document bases.

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.