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

First, questions 1 and 5 which deal with XPath 2.0.

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.

The rest you will see here is a personal opinion, which is more than I 
probably should say:

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

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

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

In my opinion, XPath 2.0 does not yet enjoy general agreement outside of 
the special-interest group that is creating it.  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 13:28:15 UTC