[
Lists Home |
Date Index |
Thread Index
]
At 10:47 AM 9/25/2002 -0700, Dare Obasanjo wrote:
> > From: Jonathan Robie
> > [mailto:jonathan.robie@datadirect-technologies.com]
> > Sent: Wednesday, September 25, 2002 10:31 AM
> > To: Dare Obasanjo; xml-dev@lists.xml.org
> >
> > At 09:19 AM 9/25/2002 -0700, Dare Obasanjo wrote:
> >
> > >There aren't 15 implementations of XQuery in compliance with the
> > >current family of specs
> >
> > But were there 15 implementations of XML parsers that were up
> > to date 6 months before the release of XML? XSLT? SAX? DOM?
> > Of course early implementations are often incomplete or not
> > up to date, and that has been true of every spec I have been
> > involved with. And look at the interesting mix of large and
> > small vendors, academics, and hackers:
>
>You can't have it both ways. You can't on the one hand claim 15
>implementations exist for XQuery then in the exact same email make
>excuses for the fact that none of them is actually written to the letter
>of the spec. Does my half hearted Lisp implementation from my Languages
>& Translation class in college also count as a Common Lisp
>implementation?
A substantial implementation is evidence of implementability, even if it is
not written to the letter of the spec during the Working Draft phase. What
do you expect - the spec is not finished, there are no conformance suites,
and the language is still evolving on significant points. It's hard to hit
a moving target, and that's why most specs I have been involved with have
had either 0 conformant implementations, or 1 conformant reference
implementation, until the language became stable.
If you want to withhold judgement until the language is finished, that's
fine. But if you want to claim the language can not be implemented, I
believe the evidence is to the contrary, since most of the features of the
language *are* being implemented. Are there particular aspects of XQuery
you hold to be non-implementable? If it is non-implementable, what is your
company planning to do now that it has so loudly announced support for XQuery?
It is definitely true that some aspects of the type system are new and
changing, and have not yet been adequately tested by implementations. We
won't be allowed to become a recommendation until we have implementation
experience with these things.
> > It's quite true that XQuery is more complex to implement than
> > an XML parser. That's a way of measuring cost. It's also true
> > that a car is more expensive than a bicycle. I would only buy
> > a car instead of a bicycle if I thought there was a benefit
> > to doing so. Traditional cost/benefit analysis looks at both
> > the cost and the benefit, not just the cost.
>
>I'm sure any real cost/benefit analysis of XQuery will throw out most of
>it (especially the dense, unreadable and incorrect mess that is the
>formal semantics) and work with a small subset. Similar to how most best
>practice guides for W3C XML Schema and C++ encourage limiting projects
>to a useful subset.
I don't understand what you are suggesting here. The language document
(www.w3.org/tr/xquery) is pretty precise even without the formal semantics,
which are a formal definition of the language. The user never reads or sees
the formal semantics, and there are no features that they can choose to use
or not depending on whether they want to use what's in the formal
semantics. Except for static typing - the formal semantics tell the
implementation how to spot some type errors, but that's nothing that shows
up in the user's query.
So what subset of XQuery are you suggesting people use to avoid the formal
semantics?
Jonathan
|
