RE: XPath DOM and XPath 2.0 (Was Re: Comments on DOM XPath Interface)

> With respect to XPath 2.0, there is no intention for this API
> to ever be
> compatible with XPath 2.0.  That is the official position this
> specification takes, and I think it is the only reasonable one, since
> XPath 2.0 is a drastic change and one that is not at all
> final.  It is
> not worthwhile at this point to delay a very practical path
> to XPath 1.0
> worrying about XPath 2.0 which in all likelyhood is not reasonably
> compatible.  I think this is clear in the issues in the specification.

Firstly, I think the level of backwards compatibility that we are achieving
in the current drafts of XPath 2.0 is a great deal better than was
originally feared, and I think that in the final specification, it will be
better still.

Secondly, I think the broad outline of XPath 2.0 is now pretty stable.
Certainly, the notion that the result can be any sequence, of atomic values
or nodes, is quite clear, and I think that structuring XPathResult on this
basis would not only make the transition to XPath 2.0 easier, it would also
give a cleaner interface for XPath 1.0.
>
>
> I think it is clear that XPath 2.0 will be much less
> compatible with DOM
> and incompatible with XPath 1.0, which seems to be the intent of its
> creators.

No, I think you're quite wrong there. It's true that some of the XQuery
people at one stage wanted to make drastic changes to XPath, but if it had
gone that way, we wouldn't have been able to call it XPath.

  I think we have to consider Path 2.0 a completely
> different
> model with different requirements.  I would love to see the XPath 2.0
> data model clarified even to the point where I can imagine it in my
> mind, let alone build a mapping onto DOM, but my own personal
> attempts
> to communicate with those who claim to understand this model have
> failed, as well as attempts to become involved in the
> definition of the
> model representing a more practical point of view required to
> map it on
> to DOM and thus web content containing Javascript.

I think the XPath 2.0 data model (at http://www.w3.org/TR/query-datamodel/)
is pretty clear. What aspects do you think require clarification? And who
did you communicate with? I don't think that it is significantly different
from the XPath 1.0 model except in one respect, the addition of type
information derived from a schema.
>
> For example, unless it has changed since I last sent in
> questions which
> were never answered, XPath 2.0 claims that these sequences are always
> ordered in document order.  But what is the document order of
> a string?

Which sequences? Sequences can be in any order. Certain operations, for
example the "/" operator in path expressions, and the "|" (union) operator,
produce sequences that are always in document order. Other operations
produce sequences in different orders. Operations that can produce a
sequence of strings do not produce output in document order.

>  Strings have no document order!  What if you have a mixed sequence
> consisting of strings and nodes?  How about namespace nodes?  If they
> have no identify, ownership, parentage, what is their document order?

Namespace nodes have open issues in the XPath 2.0 model. The proposal that
we are currently debating is that a namespace node should have no parent,
and that its identity and document order essentially become
implementation-defined. This is to allow implementations to share namespace
nodes between elements, reducing overhead, especially for implementations in
languages where allocating new objects is expensive.
>
> Perhaps a deeper question would be what is the point of these
> changes in
> XPath 2.0, and why would DOM implementations want to support them.

I guess the main benefit of XPath 2.0 is that it gives access to typed
values rather than just text. It also makes the language relationally
complete, allowing certain join operations that were impossible in XPath
1.0. Along with this comes a richer library of functions and operators. But
I think the reason DOM implementations will want to support XPath 2.0 is
that many DOM implementors also implement XSLT in the same product.

> I have been told repeatedly that compatibility with DOM is not at all a
> consideration in XPath 2.0, so it seems we are forced to take this
> position.

I don't think compatibility with DOM was a requirement for XPath 1.0; I
don't see XPath 2.0 making the situation either better or worse.

> On the other hand, trying to anticipate what XPath
> 2.0 will
> really look like if released is probably not a good way to
> spend our time.

I agree that you can't have hard dependencies on XPath 2.0. But I think you
should look at the way things are moving and make sure your interfaces are
extensible enough to cope with likely eventualities.
>
> In my opinion, XPath 2.0 does not yet enjoy general agreement
> outside of
> the special-interest group that is creating it.

If you have specific criticisms either of the published XPath 2.0
requirements list, or of the first draft specification, we will be pleased
to hear them.

Michael Kay
Software AG
home: Michael.H.Kay@ntlworld.com
work: Michael.Kay@softwareag.com

  If XPath 2.0 ever:
>
> 1.  becomes a recommendation,
> 2.  is considered highly valuable to DOM users
> 3.  has a model that is comprehensible and usefully mappable to DOM
>
> Then it is time to sit down and consider a new API for it.
>
> Ray Whitmer
> rayw@netscape.com
>
> Michael Kay wrote:
>
> >1. It is likely that XPath 2.0 will relax some of the rules
> concerning
> >namespace nodes. In particular, rules concerning their
> identity, parentage,
> >and position in document order. These relaxations are
> designed to make
> >namespace nodes easier to implement without removing any useful
> >functionality. The DOM might consider anticipating these
> changes, at the
> >very least by a note advising users not to rely on these properties.
> >
> [...]
>
> >
> >5. In designing the XPathResult interface, it would be a good idea to
> >anticipate the XPath 2.0 data model. In XPath 2.0,
> everything is a sequence;
> >it is possible to return a single node, or a sequence of
> strings. This might
> >suggest separating the notion of result type into two parts
> (a) is it a
> >singleton or a sequence, (b) what type are the items?
> >
>
>

Received on Friday, 29 March 2002 17:15:54 UTC