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

Joseph Kesselman wrote:

>Y'know, I'm currently looking at the XPath2 data model -- which, by the
>way, is also the basis for XQuery and XSLT2 -- and I don't see major
>conflicts with the DOM.
>
Only continuing to ignore issues such as the ones I just re-asked, I 
think.  This is not the first time the questions were asked, but if you 
have answers now, please give us the benefit of them.

>Yes, there are some things which are a nuisance, such as the concept of
>"namespace nodes" -- but the current draft says namespace nodes have no
>parent, which fixes a major problem we had in supporting XPath 1.0.
>
If they had eliminated namespace nodes, that would have made eliminated 
that problem.  Eliminating the parent makes it worse, not better, 
because it makes the two critical concepts of order and unique identity 
that much more difficult to understand with respect to namespace nodes. 
 There are big monsters lurking there, in my experience, and yet the 
issues still do not seem to be on the XPath 2.0 radar.

>Admittedly, the XPath2 Data Model is still a moving target, and if we don't
>want to wait for them there is a risk that we may not match what they do.
>So if we really want to go into Last Call _now_, we don't have much choice.
>
It seems that you are questioning whether the DOM XPath specification is 
in last call.  What hope has there ever been for this from the XPath 2.0 
rework?

This current XPath DOM specification is supported in the Mozilla 1.0 
release, and that implementation has undergone many changes to match 
every time there were legitimate reworkings of the specification.  The 
standardization efforts would seem wasted if those who have stood on the 
sidelines without meaningful discourse or apparent interest were 
permitted to now kill the specification at this late date.  This is why 
the decision was made by the working group early on based upon the 
realities rather than wishful thinking.  Feedback has been taken from 
users all along the way, and I have seen nothing yet to cause any 
realistic regret of that decision.

>Of course the users' response to the DOM Xpath LC may be "Wait for XPath2".
>If that's really their preference...
>
I would hope any such users would enumerate their real use cases for why 
we should wait.  I would suggest that those users go off and make their 
own XPath 2.0 API for their uses, and if there is really sufficient 
interest and resulting usability, I am sure it will become a standard 
sometime after XPath 2.0 is released.  If you are trying to advocate 
that position yourself, then please give some meaningful detail on the 
basis and use cases for your objections.  As we saw with NodeIterators 
in the Traversal spec, wishful thinking does not make a good API that 
will be implementable and usable (that is why Mozilla also cannot claim 
to implement traversal -- the ill-concieved NodeIterator).  Where is 
your DOM-based XPath 2.0 implementation?

Ray Whitmer
rayw@netscape.com

Received on Friday, 29 March 2002 17:32:32 UTC