- From: Arnold, Curt <Curt.Arnold@hyprotech.com>
- Date: Mon, 16 Jul 2001 09:03:33 -0600
- To: "'www-dom@w3.org'" <www-dom@w3.org>
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 http://www.w3.org/2001/XMLSchema 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 http://www.w3.org/2001/XMLSchema", 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