Re: XPath DOM and XPath 2.0

>
>
>I think all that's being suggested is that we might want to consider
>whether a few relatively small changes might allow that extension to happen
>more smoothly.
>

I encourage your suggestions on how that could be done with a few 
relatively-small changes.

What I thought was being suggested was:

>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.
>
I think if the user cannot rely on these following the XPath 1.0 
specification in terms of order, identity, and ownership, it is 
debatable whether we should have added it, because it was done for 
completeness.  The object itself probably doesn't make sense in XPath 
2.0 (not that XPath 2.0 has even resolved the issues surrounding these 
changes).

>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?
>
I do not think any attribute or method of XPathResult would be the same 
after such a change, because all of the methods are involved in getting 
single simple values or sets of nodes, with spill-over changes into 
other interfaces as well, especially where they deal with request and 
result types.  I do not see how any of this would make it as easy for 
the XPath 1.0 user.

Sorting concepts are entirely different, because however we may try to 
interpret the XPath 2.0 document, it seems illogical for the user to be 
able to request an arbitrary sequence in XPath 2.0 in document order, 
because strings have no document order.

Even liveness issues in the snapshot, assuming we still even have one, 
become quite strange because now in a snapshot, you have nodes which 
mutate and strings which came from the same nodes which do not.

While the XPathResult interface itself isn't one I originally thought we 
should have and it might be nice for XPath 2.0 to eliminate the new node 
type, I don't see any proposal here for "a few relatively small 
changes".  This is all a result of basic incompatibility between XPath 
1.0 and XPath 2.0, not to mention ongoing uncertainty in the spec.

And there are a number of additional concepts to consider if you really 
want to think about XPath 2.0:

For example, XPath 2.0 supports construction of new node hierarchies, 
which are subtly different from the DOM constructions, not to mention 
very incompletely defined.  I believe that the XPath operations must be 
reconciled so that they are possible / practical in DOM before it is 
possible to think about an XPath 2.0 implementation on top of DOM.  I 
believe (but am by no means certain) that in the XPath model, you are 
expected, for example to construct namespace nodes and pass them to the 
elements you construct.  What does that mean in DOM?  All we have done 
thus far is to correctly model a read-only DOM into XPath, but modelling 
a mutable DOM from XPath to DOM seems like a much bigger challenge.

I am not saying this to discourage discussion, but to encourage everyone 
to actually think of and propose what such changes would look like, not 
only to the DOM XPath specification, but also to the XPath 2.0 
specification.  Also to poke holes in what I have said above, or perhaps 
even read the 2.0 specification more closely and find more problems that 
I have missed.

Ray Whitmer
rayw@netscape.com

Received on Tuesday, 2 April 2002 07:23:13 UTC