[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 09:18 AM 9/26/2002 +0100, Bill de hÓra wrote: >Of course. The problem with languages and specifications conceived as >though they were the technological analog of finger food is not choosing >a subset (given a platter, any fool can pick and choose), but making >sure all the subsets usefully intersect. If there is a useful (that is, >interoperable) intersection to be found with such a specification, it >often becomes the basis for a future specification, the analog of a >square meal, whose creators will be praised for deciding what to leave >off the plate. Never trust a silver platter. You seem to be implying that XQuery is a really big language. It is certainly bigger than Quilt was, mainly because of support for types. But if you look at the grammar [1] the whole language is 89 productions, and most of that is either the XML grammar, which you obviously need for constructing XML, or the XPath grammar, which you obviously need for finding things in documents. Add to that FLWR expressions, used for joins, function definitions and function calls, and the ability to declare namespaces and import schemas, which all seem obviously important, and the rest is small change. Except for the syntax for matching types, which is larger than I would prefer (10 productions out of the total 89), largely because of the structure of XML Schema's type system. I believe that there are clear uses for strongly typed data [see 2], but not all users will want this, and not all implementations will provide it. So I think that there will be one community that uses strong typing, and another that does not. There will also be some implementations that provide strong typing statically, and others that provide it only dynamically. We have three different conformance levels to accommodate these audiences [3], but two of them use exactly the same language and simply have different requirements on error reporting, and the other simply disallows schema imports or naming of types that are not built-in to XML. If you leave out the syntax for matching types, I believe that XQuery is roughly the same size as XSLT + XPath. Incidentally, section 5 of the XQuery document [4] shows scenarios for which people had asked for special syntax, demonstrating that these things can be done without additional syntax because of the compositionality of XQuery. We have always emphasized compositionality instead of adding new syntax. I don't think that there is that much more that could logically have been left off the plate, except for schema import and support for all the types that enables, and we have a conformance level that does leave that off. We have people asking for features that we do not support and probably will not support in XQuery 1.0. I think that's a good sign. Jonathan [1] http://www.w3.org/TR/xquery/#id-grammar [2] http://www.w3.org/TR/xmlquery-use-cases/#strong [3] http://www.w3.org/TR/xquery/#id-conformance [4] http://www.w3.org/TR/xquery/#N401EFC
|
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
|