Re: Draft Note on DOM Support for XPath 2.0

On Wed, 3 Sep 2003, Gareth Reakes wrote:

> I think it is a mistake to regard XPath2 in the same way as XPath1. I am
> coming round to Elliottes view that a completely separate interface may be
> required to fully harness the abilities of XPath2.

This was our original take on XPath2, which was why we did not address it.

However, others also quite familiar with XPath2 have tried to insist that
both could be served by the same API.  My reading of the XPath 2.0 spec
does not make it clear to me that the changes you request are essential
in a DOM API.  The DOM API really is designed to be a way of easily selecting
nodes and values from the DOM tree, as described in the requirements document.

We will certainly get feedback from some who wrote the XPath 2 specification
before even publishing this as a note, who were the ones who wanted the API
as an extension (or as a single API that addressed both) and see if they
think it is on the right track.

It is not clear that what we have proposed is inappropriate to provide XPath
2.0 for DOM applications.

We know things are missing, and it was never our intent to do more than
make a useful API for DOM users to use XPath to simplify tasks such as
navigation, not to replace a full XPath implementation that was not related
to DOM nodes, as your use cases seem to imply by making non-nodes the context.
A complete API would require a great deal more work and would provide
additional context setting, supplying of user variables and arguments, etc.
but we do not presently have the charter to take even this limited API through
to become a recommendation.

What we have is much better at accomplishing valid DOM XPath tasks than
Node.select because it addresses namespaces and a number of other essential
things ignored by these previous APIs.  If it weren't for problems in
Node.select, we could have standardized that and satisfied 90 percent of
the needs of DOM users.

Ray

Received on Wednesday, 3 September 2003 11:44:03 UTC