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] Fwd: War of Attrition (was: [xml-dev] Underwhelmed (WAS:

[ 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

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 



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

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