DOM 3 XPath: XPathEvaluator usage issue

It seems to me that a very common usage of XPathEvaluator will be to:

1) Create an XPathNSResolver for a given context node
2) Evaluate an expression, passing the resolver just created, against the
same context node

Since the same object that implements createNSResolver implements evaluate,
couldn't we save users a bit of trouble by simplifying this common case?  I
can think of several alternatives:

A) An alternative signature of evaluate that takes no 'resolver' parameter. 
The implementation creates an XPathNSResolver internally based on the
'contextNode' parameter.

B) An alternative signature of evaluate that takes no 'contextNode'
parameter. The context is derived from the 'resolver' parameter.  This would
mean adding 'contextNode' as a readonly attribute of XPathNSResolver.  Apart
from the rest of these request, if a user only has an XPathNSResolver
interface, it would be convenient to have a way to get the context node that
the adapter was created from.

C) Allow the XPathNSResolver parameter to evaluate to be null without the
exception.  This implies that the implementation should again create it's
own resolver from the 'contextNode' parameter.  Granted, this loses the
ability to verify processing of non-namespaced XML.  Another alternative is
to use a distinguished instance of XPathNSResolver to indicate that no
resolver is needed, or that one should be created from the contextNode
parameter, either way.

The life time of any internally created XPathNSResolver would be left as an
implementation detail.  This permits implementations to cache a resolver
against the contextNode, or to simply create and destroy a new one for each
call to evaluate.

Perry A. Caro
Adobe Systems Inc.

Received on Saturday, 20 July 2002 10:32:30 UTC