OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] XSLT and XQuery

[ Lists Home | Date Index | Thread Index ]

At 11:03 AM 1/7/2002 -0500, Adam Turoff wrote:

>This is a specious analogy.  Java and C++ are competing solutions within
>the problem domain of designing applications.  That they are similar or
>related is irrelevant.
>XSLT and XQuery are companion solutions playing in the same pond, but
>are not intended to be competing or even interchangeable.  Therefore,
>where similarities exist between XSLT and XQuery, there is a stronger
>drive to make them compatible than there would be with Java/C++/C#.

I think that XSLT and XQuery have the same capabilities, but each is more 
convenient for a given class of applications, and XQuery has been designed 
with more of an eye to type safety and optimizability for large data 
stores. For many applications, they may well be competing languages - 
people could use either, and will have reasons for choosing one or the other.

I also think that Java and C++ often play in the same pond. I live in a 
world where Java and C++ are often used to develop different parts of the 
same systems. I expect XSLT and XQuery to be used in the same way.

> > I am not yet convinced that there is an equally urgent need to
> > unify element constructors, and if we did so, I would think that would 
> best
> > be done as part of a deeper integration of the two languages altogether.
>Like all WD releases, XQuery 1.0 contains this wording:
>         This document is a work in progress. It contains many open
>         issues, and should not be considered to be fully stable.
>Your statements tell me that either this is a hollow warning, and
>these WDs are simply a preview of XQuery 1.0 that is about to be
>released shortly and be substantially similar to what's being
>discussed today.

I said that I do not see a strong need to unify element constructors across 
XSLT and XQuery, and you say that proves I don't really believe that XQuery 
is a Working Draft. I do not see how your conclusion follows from my 
statement. Having read your message, I still believe that XQuery is a 
Working Draft, and I still don't see an urgent need to unify element 
constructors across the two languages.

>That is not to say that the goal should be a perfect XQuery 1.0;
>XML 1.0 2ed is far from perfect.  But with all of the pushback from
>xml-dev, there are some serious issues with XQuery 1.0 that lack
>conceptual cohesion with the rest of the XML world (pseudo-XML
>syntax, divergence from well-established semantic forms used in
>XSLT, lack of update support) and really ought to be addressed in
>this release.

Here's my take on these three areas so far:

1. XML syntax for element constructors

We've heard good arguments on both sides of this issue. I don't think the 
discussion is over. If everyone were convinced to do so, it would not be 
difficult or time consuming to eliminate those productions from the XQuery 
grammar. This is just syntax - we can argue about what the best syntax is, 
but there's no reason to assume that our decisions on this would 
dramatically affect our schedule. My earlier statements about time had to 
do with deeper integration with XSLT, not with element constructors.

2. Eliminate divergences from XSLT

So far, many people on this list seem to be saying that sharing a common 
data model and type system with XPath and XSLT is important, but that XSLT 
and XQuery can be syntactically different. This is also my view. You seem 
to disagree, but I am not certain, because you refer to "well established 
semantic forms", not to syntax. What are the "semantic forms" to which you 
refer, and how do you think XQuery should be designed to take the semantic 
forms of XSLT into account?

3. Updates

I previously asked the following question: would you rather have XQuery 1.0 
six months earlier without updates, or six months later with updates? I 
received answers on both sides of the fence. I think it was pretty clear 
that people do not want updates a year or two down the road.

So my personal take is that (1) does not really impact our timelines, 
though it strongly affects the syntax of the language, (2) may not be 
important enough to risk our timeline on, but I'm not completely certain 
that I understood your intent, and (3) is very important, but might also be 
done as an addition to XQuery 1.0.

>  XQuery implementations are likely to take a
>decent sized team many months to create and test, which makes it
>all the more important to get this REC as good as possible, since
>the cost of interoperability problems is much greater than with
>XML parsers.  It would be folly to expect an XQuery specification
>to be done right in about roughly the same amount of time it took
>to get the XML recommendation right.  Given the state of the art,
>a factor of four seems quite reasonable.

Test suites are going to be very important. The use cases, of course, 
provide an initial set of tests, and this is what most of the approximately 
twelve current implementations seem to have been using. But we are going to 
need more in-depth test suites to prove interoperability. Do note, however, 
that the formal semantics of XQuery mean that it is also rather precisely 
specified, which can be worth a lot of testing.

The factor of four you suggest says we should spend a total of 6 years on 
XQuery, rather than the 3 years that I would prefer. I presume most of this 
time would be spent with adopting the "semantic forms" of XSLT to which you 
refer above?



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS