RE: Namespace resolver in DOM-XPath (suggests additional Node met hod in Core)

I guess it depends on the relative proportion of the use cases and the relative costs.  My gut feeling is that use case a would be more far prevalent and that when you had a use case B then the query
would be pretty shallow in the document and assembling a complete list of the in-force namespaces would be fairly inexpensive, at least compared to the XPath evaluation.

You definitely need to allow a use case a query without requiring the caller to define a class or build a dummy document just to resolve the namespaces in a hardcoded XPath expression.

Using a string in my estimation seems to be the best solution for use case a and a tolerable solution for use case b.  

Adding a createNamespaceResolver method to XPathEvaluator that took an space separated lists of prefix/uri pairs would be helpful if NamespaceResolver must stick around.  

However, it seems to be trying to provide a potential optimization to the rare case at the cost to each implementation of the more common case.

Received on Monday, 16 July 2001 15:04:06 UTC