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] XQuery and DTD/Schema?

[ Lists Home | Date Index | Thread Index ]

At 11:15 PM 7/6/2002 -0600, Uche Ogbuji wrote:

>So you say.  I've conceded in other messages that these separate groups 
>will just have to keep in opposition to each other, and the marketplace 
>will decide.   You seem pretty confident that the long term market of XML 
>will favor sophisticated type systems and other data binding issues mixed 
>into core XML processing.

Is XQuery core XML processing? Are these groups really separate? I use a 
lot of untyped XML, and I do a lot of work with XML that does not involve 

Hey guys, have you noticed that XQuery adds nothing at all to XML? It 
merely supports XML as currently defined by the W3C, including well-formed 
XML, XML governed by a DTD, and XML governed by XML Schema. We don't change 
what an XML parser does, we don't change the XML APIs, we merely provide a 
new language for processing XML.

>I predict that this approach will flop.  We shall see, but I'll go one up 
>on Sean McGrath's bet: if all this overgrown welter of "object XML" is 
>still in serious play in 2006, and I show up at any XML conference, it 
>will be in a tutu and an afro with a chin strap.

Since XQuery is a functional language, with no concept of objects, and no 
complex datastructure other than XML itself, I continue to think that 
'object' is a strawman. Many languages have datatypes. Yes, we do support 
XML Schema's inheritance, but that doesn't make XQuery object oriented. 
(And I personally wish XML Schema did not have inheritance, but I lost that 

At any rate, since 2006 is only four years off, are you saying that you 
will need a change of wardrobe if XQuery is in common use? If so, you may 
want to save the following URLs:


Will the tutu be pink?

Or are you saying that the market will demand a simpler way to associate 
datatypes with XML? If so, I hope you are right.

> > You have not yet shown me how to use these multiple layers to do what
> > XQuery was designed to do - query large persistent stores of XML, views of
> > non-XML data, allow queries to integrate the two,
>These strike me as precisely the sorts of matters that are not even yet 
>ready for standardization.  First of all, querying a lot of persistent XML 
>and viewing non-XML data in XML forms are very different matters, and very 
>different needs.  The latter is useful regardless of how much data is in 
>play, and whether or not it is persistent.  It is not ready for 
>standardization because it is such a varied matter.  The RDBMS vendors all 
>have different approaches to the problem, and on the OO front there are 
>things such as JXPath.  I'm not sure why this diversity needs to be scrapped.

Interoperability between systems is one reason. Or letting people learn one 
way of doing something and using it for XML files, RDBMS, and native XML 
stores, rather than learning a different approach for each vendor's product 
in each environment.

Of course, establishing a standard query language does not prevent people 
from using other approaches if their problem is not solved by the query 

You are right that XQuery is pitched at a wide variety of needs. So is XML. 
Sometimes one solution can cover many needs.

>I think there are a lot of lessons to learn before imposing standards on 
>this area.

A lot of experts in the field think that it is time for something like 
XQuery to be developed. That doesn't mean there are no issues - 
optimization and mapping of XQuery to foreign data sources is a hot 
research topic.

Will history say XQuery was premature? I don't think so, but let's discuss 
this in 2006.



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

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