Namespace resolver in DOM-XPath (suggests additional Node method in Core)

The current DOM XPath working draft defines an interface that must be implemented by the calling code to map the prefixes used in an XPath query to namespace URIs.

In a previous message, I described two use cases for the namespace mapping:

a) The namespace mapping is fixed by the calling application.  For example, a query that wanted to find all the elements in the namespace regardless of the namespace
bindings used in the document.

b) The query should be interpreted by the namespace mappings in effect at a specific node.  For example, if an XPath query is delivered in an XML document, then the query should be interpreted using
the namespace-prefix mappings in effect for that node.

In the previous message, I suggested that it would be more convienient for the caller for use case A to use an object supporting the standard platform map interface than to define a class derived from
NodeResolver and that it would be more convienient for use case B just to pass in a Node.

I believe an even better solution is to simply express the mapping of prefixes to namespaces in a string containing prefix/uri pairs followed by the default namespace URI, if one exists.

This would allow use case a callers to do something like:

elements = xeval.evaluateAsNodeSet("//xsd:element","xsd", doc);

To support use case b, a method would need to be added to Node in the Core spec to provide the in-force namespace mappings in this format.  For example:

elements = xpath.evaluateAsNodeSet(query.getValue(), query.getNamespaceBindings(), doc);

Received on Monday, 16 July 2001 11:44:25 UTC