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 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.


[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


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

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