[
Lists Home |
Date Index |
Thread Index
]
On Fri, Jan 04, 2002 at 06:43:22PM -0500, Jonathan Robie wrote:
> There are actually many constructs which are similar, but different, in
> XSLT and XQuery, just as many of the features of Java and C++ are similar,
> but different. That does not necessarily mean that Java and C++ should be
> unified.
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 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 (have been led to) believe the intent of the WD is to flesh out
serious shortcomings with technologies in development, such as the
gratutitous psuedo-XML syntax of XQuery, the needless divergence
from well-known semantic behaviors that are substantially similar
to those found in XSLT, and the lack of update support.
> This is the sort of thing that requires careful exploratory work by a small
> group over time, and I don't think it should be placed on the critical path
> for XQuery 1.0.
Which critical path would this be? The critical path to ship the current
work, or the critical path to develop the best, most conceptually sound
XQuery specification?
The XML recommendation spent roughly 15 months in development from the
first public working draft (http://www.w3.org/TR/WD-xml-961114.html)
to the first recommendation. Looking back, XML as it exists today
after the second edition is substantially similar to the initial SGML-Lite
approach from five years ago. I attribute this to a variety of factors,
including the tight focus of that group and the small scope of that
problem. An XML Parser is intended to be easily implemented by a
practitioner already skilled in parsing and compiler design.
XQuery is neither a tightly focused group (*7* editors?), nor a
small scope problem. 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. (It took XSLT longer than
the 14 months from first WD to first REC, once the early straw-man
syntaxes are included; that it was done so quickly is more of a
testament to James and his depth of experience than anything else.)
> Here are some costs I am concerned about:
>
> First, we have just spent an entire year working together to unify XPath
> and XQuery, and we are not yet done with that work.
Thank you. This is undoubtedly the best path to take.
> Unifying the remaining
> portion of XQuery and all of XSLT would certainly take a significant amount
> of time -- I would estimate it as at least an additional year.
It sounds like that would be time wisely spent. I find it less
important to get XQuery 1.0 out the door "quickly", and more
important that XQuery 1.0 is substantially similar to the XQuery
that will be in use in five-to-ten years' time, much like the 1996
working drafts of XML are substantially similar to XML as it is
used today.
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.
Z.
|
