Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Fwd: War of Attrition (was: Underwhelmed (WAS:
 At 10:47 AM 9/25/2002 -0700, Dare Obasanjo wrote: > > From: Jonathan Robie > > [mailto:jonathan.robie@d...] > > Sent: Wednesday, September 25, 2002 10:31 AM > > To: Dare Obasanjo; xml-dev@l... > > > > 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
