[
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:
update
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:
http://www.lehti.de/beruf/diplomarbeit.pdf
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:
http://www.oasis-open.org/committees/relax-ng/xsd.html
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
>issue]
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.
Jonathan
|
