[
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
XQuery.
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
fight.)
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:
http://www.tutu.com/
http://www.sillyjokes.co.uk/dress-up/wigs/big-afro.html
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
language.
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.
Jonathan
|
