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] FW: [ANN]: XQuery: A Guided Tour

[ Lists Home | Date Index | Thread Index ]

xsi:nil and key/keyrefs are one part of the problem. The existence of union types, xsi:type and substitution groups also are problematic but this is mainly due to the fact that XQuery is statically typed.  
 
As for XQuery being able to support other XML schema languages in future, this is nice but I'm curious as to what exactly this means in practical terms. The working group already has seen the problems caused when one group builds a "type system" (and I use the term loosely) which they believe can work for some future language only for their assumptions to come out wrong. I originally was of the mind that this was a laudable goal of XQuery and still think it is a laudable goal to have it in the data model but wonder how feasible it is to actually create an XQuery implementation with what is basically a "pluggable" type system. A validation language with pluggable datatypes (which are basically custom checking on string values) like RELAX-NG has is fairly straightforward enough but a creating a pluggable type system where you have to deal with issues like type promotion & type substitutability is a bit harder. 

________________________________

From: Jonathan Robie [mailto:jonathan.robie@datadirect.com]
Sent: Tue 9/30/2003 7:13 AM
To: Rick Jelliffe; xml-dev@lists.xml.org
Subject: Re: [xml-dev] FW: [ANN]: XQuery: A Guided Tour



At 03:56 AM 9/30/2003, Rick Jelliffe wrote:

>And the design requirement that the datatypes must "define a type system
>that is adequate
>for import/export from database systems (e.g., relational, object,
><http://www.olapcouncil.org/>OLAP)"

Well, as you know, I agree with you. If XQuery were to design its own
optimal schema language, I doubt that it would have xsi:nil or key/keyrefs
- features specifically provided for the sake of future query systems. I
think it was unwise to try to guess what the query language might become
later on.

>Other good quote, showing the false economy of non-modularity in big specs:
>
>* XQuery's design influenced by XML Schema's provision of
>   "a set of primitive types, a type-definition facility, and an
> inheritance mechanism...
>    (and) the validation process... Nevertheless, members of the working group
>    attempted to modularize the parts of the language that are related to type
>    definition and validation, so that XQuery could potentially be used with
>    an alternative schema language at some future time."

I think this is important.

Jonathan


-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>







 

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

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