Re: DOM Level 3 Events (and XPath)

On Wed, 30 Jul 2003, Christian Parpart wrote:

> Since no implementation will provide XPath 1.0 *and* XPath 2.0 inclusivily.
> I'd propose to keep that name XPathResult and just extend/modify this
> interface. I really has no need to be backward compatible since we're talking
> about a big version move (vom 1.0 to 2.0 ;)
>

While the implementation will not be required to provide both,
I consider it likely for some implementations to provide both.  This
is easy because seperate request codes will be used.  While the
application will choose to use one or the other by choosing the
corresponding request codes, the implementor may want to provide both
depending upon applications usage.  Using the hasFeature method, it
is possible to test whether the implementation supports the one
required.

> I suggest to provide generic XPathResult interface that provides some kind of
> read-only property telling me what kind of result I have.
> You may compare this to Node.nodeType() that can be implemented very fast by
> just returning a member variable inline (in case of C++).
>

It is never necessary to test what type of result is present.  That is
already obvious from the request code.  This is already very similar to
Node.nodeType.  I hope soon to post a note containing more details.

Since the result type is sufficiently different for XPath 1.0 and 2.0,
a cast is required, but the cast should never fail except in the case of
a programming error.

Ray Whitmer
ray@xmission.com

Received on Wednesday, 30 July 2003 07:40:49 UTC