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