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] The use of XML syntax in XML Query

[ Lists Home | Date Index | Thread Index ]

At 04:04 AM 1/4/2002 -0800, Dare Obasanjo wrote:

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

The main difference is in fallback conversions. You can see this most 
clearly by comparing section 2.1.2 of XQuery to section 2.1.2 of XPath 2.0. 
The fallback conversions allow XPath 2.0 to operate in a manner that is 
very compatible with XPath 1.0. They are not supported in XQuery, which 
returns a type error when XPath would attempt a fallback conversion.

> From reading the XPath 2.0 section on datatypes [0] 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 sample queries on the page 
>so one
>can compare XQuery statements to XPath 2.0 statements an thus clearly see the
>differences (if any).

Any expression in XPath 2.0 and XQuery 1.0 will either return the same 
result in both languages, or return an error in XQuery because of the 
stronger typing.

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

[ !!! SNIP !!!]

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

XQuery must support both well-formed documents that have no schema and XML 
Schema documents that do not use simple datatypes. A document defined using 
a DTD can easily be converted to a document using a schema without simple 
datatypes. In practice, I think that documents with DTDs will be treated as 
such by most products.

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

For reference, 3 was updates.

The W3C has made no decision not to pursue this until further notice. 
Several vendors are implementing something more or less based on a proposal 
developed quite a while ago. I am now working on an updated version of this 
proposal. I agree with you that it would be best to have vendors implement 
the same thing, which is why I am working together with other vendors on this.

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

For reference, 4 is presentation, including HTML conversion, and 3 is updates.

But element constructors and computations on the original structures are 
essential as part of updates. For instance:

   for $e in //employee
   where $e/name="Dare Obasajno"
   replace $e/salary
   with  <salary>{ $e/salary * 5 }</salary>

Also, data-oriented transforms of XML are very important for data 
integration, which is not a presentation issue. I think the transformations 
of XQuery are very important - and they exist! This part is already 
defined, so let's not undefine it....

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

I agree. Splitting it from XQuery does not help get it out faster, though.

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

Best dealt with by an update proposal ;->

How do you like this as a starting point:


But as I said earlier today, this will certainly change because I am 
working with other vendors on an updated proposal.

>2.) Over reliance on XML schemas for strong typing

Both XPath 2.0 and XQuery use the XML Schema built-in types, so I do not 
see a real difference between the two here. You could give XQuery less 
strong typing by adding the fallback conversions to XQuery, but is this 
something you would really want? The main virtue of the fallback 
conversions is compatibility with XPath 1.0, IMHO, and XQuery does not 
really have that issue to the same extent. And the fallback conversions are 
not necessarily intuitive to someone without extensive XPath 1.0 experience.

And I think that the XML Schema built-in types are one of the things that 
tend to unify the XML Schema and RELAX-NG camps. I assume you are familiar 
with the guidelines for using XML Schema built-in type with RELAX-NG:


Of course, you could also use other type libraries, but in practice, I 
think the built-in types of XML Schema are well-designed, and are likely to 
be used quite widely.

>3.) Element/attribute constructor syntax [even though I don't see this as an

I don't see this as much of an issue. In today's discussions, at least, it 
boils down to whether we should support both the computed element 
constructor syntax and the XML constructor syntax. The status quo, as 
reflected in the Working Drafts, is that we support both.



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

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