Lists Home |
Date Index |
----- Original Message -----
From: "Jonathan Robie" <firstname.lastname@example.org>
To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>;
Sent: Thursday, January 03, 2002 10:42 AM
Subject: RE: [xml-dev] The use of XML syntax in XML Query
> I disagree. When I speak on XQuery, people say they want XQuery now, not in
> several years. Products that implement XQuery will be released this year,
> and if the standard is not done this year, then the implementations done by
> the biggest vendor will become the defacto standard. Do you really want the
> XQuery standard to be released two years after Microsoft's implementation
> hits the market? Since Software AG is implementing XQuery, don't we want to
> be implementing something that conforms to an existing standard?
Well so far Microsoft has been good at bowing to the wisdom of the W3C when it
comes to XML technologies on at least two occasions (XDR vs. XML schemas &
MSFT XSL vs. XSLT) although I guess one shouldn't take for granted that MSFT
will continue to play ball with the W3C and abandon their technologies for W3C
standards indefinitely. As for Software AG, I have no clue about their history
w.r.t. standards and XML so I can't comment.
> I do not believe that there is a real need to change XQuery's syntax to be
> an XML-based syntax, the cost of doing so would be high, and there would be
> a very real danger of bogging down the XQuery effort entirely. David and
> Elliott both seem to feel that the computed element constructor syntax can
> be used for their purposes.
I agree completely with this sentiment.
> Most of these features came from XQuery, which adds very few new features
> to XPath 2.0. XPath 2.0 and XQuery 1.0 are largely the same language. I
> don't think it makes much sense to have these two languages be on different
> release schedules.
So if they really are the same language, minus element constructors and strong
typing what exactly is the difference between the datatype system in XPath 2.0
and that in XQuery? From reading the XPath 2.0 section on datatypes  it
looks like they share the same simpletypes as well as a strange mix of old
school XPath 1.0 types (e.g. nodes) and new school XML schema types (e.g.
complextypes). Unfortunately there aren't any sampe queries on the page so one
can compare XQuery statements to XPath 2.0 statements an thus clearly see the
differences (if any).
Also am I the only one that feels weird seeing "instance of" and "cast as" in
Xpath 2.0? Hmmm, XML's come a long way.
> I think the XML database world needs a single query language that can be
> used without extra layers of DOM, SAX, Java, or XSLT to do everyday tasks.
> And I think that the few features of XQuery that have not been taken into
> XPath 2.0, such as function definitions and element constructors, are
> extremely useful for everyday tasks.
Ahhhh, but unfortunately I don't see how XQuery in it's current incarnation is
really all that useful to the XML database world. When I think of working with
databases applications I think of the following tasks,
1.) Defining Data Schemas
2.) Querying Data from the DB
3.) Updating/Modifying Data in the DB
4.) Making the data presentable (over the web or in a GUI)
5.) Managing the database (indexes, triggers, connect/disconnect, creating
6.) Doing some application logic at the DB layer
Now with relational databases I can do 1, 2, 3, & 5 with SQL, 4 gets done via
some middletier programing language (ASP, Java Servlets , Perl CGIs, VB etc)
and 6 with stored procedures. And frankly I typically I don't usually use 6.
So all I really need is SQL and a programming language of my choice.
Now let's see how this works with XML databases
1.) DTDs / XML schemas
2.) XPath 2.0 / XQuery
3.) DOM/Proprietary XQuery/XML-based update language
4.) XSLT / XQuery
5.) Via the GUI or command line
6.) very vendor specific stuff
OK, so let's toss 6.) as being unnecessary and 5.) as not being within the
scope of the W3C since the W3C is the World Wide WEB consortium and not the
XML:DB initiative. Now we examine the rest.
For 1.) if we use DTDs, then we're at odds with 2.) since the W3C has decided
that DTDs are passe and XML schema types are de rigour despite the many
problems with the W3C XML schemas recommendation. So now we have an
environment where to do querying using modern W3C technologies users MUST
embrace W3C XML schemas regardless of DTDs or Relax NG would serve their
purpose or if they already have an NXD solution that works using DTDs.
Moving along to 3.) the W3C has decided not to pursue this until further
notice and one wonders whether by the time this is decided on there won't be
too many vendor specific mechanisms that would have become standard.
However I am most perplexed by the fact that the W3C has used XQuery to give
us 4.) before using it to give us 3.) yet claims that they are looking out for
the XML database folk.
> >- Consider an XUpdate or whatever on top of XPath 2.0 as a the next highest
> >priority, split it out from XQuery if that helps get it out faster.
> >Alternatively, graciously cooperate with some non-W3C activity to define an
> >XUpdate language cleanly layered on XPath 2.0 if the W3C does not have the
> >bandwidth to pursue it.
> Update requires element constructors.
> Element constructors are one of the main differences between XQuery and
> XPath 2.0.
This I can't argue with. As I mentioned before perhaps there needs to be an
XML data manipulation language specification built off of XPath 2.0 by some
interested party which solves the issues that XQuery has including...
1.) Lack of updates
2.) Over reliance on XML schemas for strong typing
3.) Element/attribute constructor syntax [even though I don't see this as an
THINGS TO DO IF I BECOME AN EVIL OVERLORD #35
I will not grow a goatee. In the old days they made you look diabolic. Now
they just make you look like a disaffected member of Generation X.
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com