- From: Ray Whitmer <rayw@netscape.com>
- Date: Fri, 01 Nov 2002 04:48:08 -0800
- To: www-dom@w3.org
Joseph Kesselman wrote: >On Tuesday, 10/29/2002 at 09:11 EST, "Dominic Chambers" ><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. Ray Whitmer rayw@netscape.com
Received on Friday, 1 November 2002 07:48:56 UTC