Re: Level 3 XPath doesn't feel right

> On Fri, 01 Nov 2002 04:48:08 -0800, Ray Whitmer wrote:
>>On Tuesday, 10/29/2002 at 09:11 EST, "Dominic Chambers"
>><&References=<3DC27808.4030607@netscape.com"dominic.chambers@bigfoot.com>
wrote: 
>> 
>> 
>>>1. XPathEvaluator should be implemented by objects that currently 
>>> 
>>> 
>>implement 
>> 
>> 
>>>Node, not 
>>> Document, since you need to have the context node anyway, and 
>>>node.evaluate(expr), >> is cleaner and more OO than document.evalute(expr,
node). 
>>> 
>>> 
>> 
>>In isolation, I would agree with you. However, I believe the intent was to 
>>allow stand-alone implementations of the XPathEvaluator which could be 
>>combined with DOMs that don't directly support this feature; the process 
>>of obtaining the evaluator would be different but thereafter the code 
>>would be the same, minimizing the multi-pathing/recoding needed to go from 
>>built-in to stand-alone implementations or vice versa. If we accept that 
>>goal, we do need to be able to pass the node explicitly.
>> 
>> I agree. If there were only ever going to be one implementation made
available
> by the DOM implementor, then putting it on the Node would make a lot of
sense.
> But there may even be multiple evaluators available, used for different
purposes,
> on the same set of nodes. The implementation is only available on Document so
> that applications without a place to get one that is more specific to their
requirements
> can get a default implementation in a platform-independent way. It is quite
likely that
> one system processing a DOM hierarchy may rely on an evaluator supporting a
specific
> set of extension functions, and some other implementation may have a
different set
> of functions available. Marrying it to the node would make it quite difficult
to switch
> to a different evaluator implemented for some other purpose such as a version
of XSLT
> when processing in a different environment. 


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?

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.

-Shelby Moore

Received on Monday, 16 December 2002 09:51:00 UTC