W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2002

Re: Level 3 XPath doesn't feel right

From: Ray Whitmer <rayw@netscape.com>
Date: Mon, 16 Dec 2002 09:25:05 -0800
Message-ID: <3DFE0C71.8040106@netscape.com>
To: www-dom@w3.org

Shelby Moore wrote:

>However, an alternative OO way to _GENERALLY_ attack this issue may be to have
>the Node class inherit from a base class which has QueryInterface(), if it
>doesn't already.  The idea is similar to Microsoft's COM.  IMO, this is going
>to be needed by every extension to the DOM, including the DOM Views and
>Formatting spec.
>
>Thus the multi-pathing is only in one place, base::QueryInterface().  Once you
>have the pointer (reference) to the alternative interface to the DOM, then you
>can make OO calls into that extension use a pointer (reference) to the Node. 
>The extension only needs to process it new methods, and passes rest to base
>interface.
>
>Thus it seems to me a QueryInterface() could supercede the functionality of
>hasFeature().
>
>Wish I could have been here contributing when DOM Level 0 work was going on. 
>However, it should not be that disruptive to add a new method to the base class
>for DOM Level 3?
>  
>
In DOM Level 3 working drafts, there already is a new method called, I 
believe, "getInterface" which accepts a feature name.  It has some 
issues to be worked out, but could be applied to what you have described.

But in this case, it just doesn't seem at all like the pain of adding an 
object obtainable from every node is worth it.  The alternative we have 
today is clean, modular, easy.  Many/most implementations will not ever 
build a framework for dynamically attaching things such as XPath 
implementations to every node of the tree.

>The downside to this alternative is I guess that the extension can not be
>separated from DOM, for use with alternative DOM.  However, my cusory
>understanding is that DOM already has features (getDOMImplementation()) for
>morphing itself.
>
Again, it is possible, but that does not mean that it is desirable to 
require XPath implementations to jump through these hoops when passing a 
node as an argument to a more-global evaluator is so much easier, and I 
think is easier for the user to understand, as well.

If I write a convenience routine that works with arbitrary XPath 
implementations, and the application needs it to work with a specific 
one, I like the idea of passing an XPathEvaluator much more than passing 
a feature name and querying each node.  The application might even 
supply the XPathEvaluator itself.

Ray Whitmer
rayw@netscape.com
Received on Monday, 16 December 2002 12:25:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:56 GMT