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