Re: Why not reinvent the wheel?

[Charles Reitzel <creitzel@mediaone.net>]

At 11:28 AM 2/24/01 -0500, Jonathan Robie wrote:
>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.

I appreciate your open-mindedness.  You've also been a good sport about
taking the heat for XQuery.

But do you see the cognitive dissonace some of us are experiencing here?  If
such a mapping is possible, then you have just proved that the processing
requirements for the XQuery subset are the same.


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

Without getting into semiotics - please - I don't get this one.  If both
will return the same result set against all given data sets, then they have
de facto the same semantics.  The same can be said for equivalent but
different XSLT stylesheets or XML Queries.  If they aren't semantically
equivalent, then the XSLT representation of the original XQuery was inaccurate.

If you meant something else by semantically equivalent, I submit that "same
input produces same output" is the most useful definition of semantic
equivalence in software engineering.


>On 09:51 PM 2/22/2001 -0500, Charles Reitzel wrote:
>>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?

You understand correctly.  There are throughput and latency issues that
limit the scalability of current XSLT implementations.  We share this
concern, I believe.  I just don't think XQuery, per se, contributes much to
the solution.  It may even detract from it.


>I am encouraged by the fact that several 
>universities and companies are already working 
>on XQuery implementations...

I appreciate that such implementations must be gratifying to everyone who
has worked hard on the XQuery spec.  Time will tell which ones mature to be
deployed in large scale, production environments.


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

That is a somewhat different case.  I think the XQuery group would do well
to emulate the roadmap laid out for the transition from CSS to XSLT.  This
whole discussion started when Simon StL put out a call for just such a
roadmap for the growing family of XML specs.


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

Should not be applied, then.

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

I have read Evan's paper.  I'll read it again, but I'd like to hear from you
(or any other XQuery protagonists out there): for which XQuery use cases is
XSLT an inappropriate tool?

No big time sink, I hope.  Just give us a list of numbers from
http://www.w3.org/TR/xmlquery-use-cases, and I'll go read those again, too.


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

Yup, I'm thinking at the basic, algorithmic level.  I think we basically
agree on this.  I might go further, in that I think this is where the big
gains will be found.

take it easy,
Charles Reitzel