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 ]
  • To: "Jonathan Robie" <jonathan.robie@datadirect-technologies.com>,<xml-dev@lists.xml.org>
  • Subject: RE: [xml-dev] Fwd: War of Attrition (was: [xml-dev] Underwhelmed (WAS: [xml-dev] XOM micro tutorial))
  • From: "Dare Obasanjo" <dareo@microsoft.com>
  • Date: Wed, 25 Sep 2002 10:47:44 -0700
  • Thread-index: AcJkuWEWG5s2f2xvRHKu9M1gyDu+rQAAR14Q
  • Thread-topic: [xml-dev] Fwd: War of Attrition (was: [xml-dev] Underwhelmed (WAS: [xml-dev] XOM micro tutorial))

> -----Original Message-----
> 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

<snip-list />
> 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. 
> The fact that there are this many implementations indicates 
> that some people were willing to pay the cost of 
> implementation for the benefit they think XQuery will provide 
> to their users.

The benefit _some_ of XQuery will provide to their users. 

> As for inconsistency, underspecification, and errors - could 
> you please coordinate with Microsoft's representative and 
> make sure that the issues you see are in our issues list, or 
> respond to our comments list with these? 
> (public-qt-comments@w3.org). A Working Draft is only a 
> Working Draft, as our issues list indicates. But if there are 
> important things not on our issues list, please make sure we 
> are aware of them!

Our reps know my issues as I find them.  

Self-made people have an abundance of working parts.        

This posting is provided "AS IS" with no warranties, and confers no


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

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