Additional comment on DOM L3 XPath

XPathExpression should have a reference to the XPathEvaluator that created it.


There needs to be an error code to represent a mismatch between the Xpath expression and context node.  Though it would be possible to write an XPath evaluator that would work on any DOM
implementation, it should be allowed for an XPathEvaluator implementation to only work with a compatible DOM implementation.  Something like:

XPathExpression xpathdoc1 = ((XPathEvaluator) doc1).createExpression(...);
XPathSetIterator resultSet = xpathdoc1.evaluate(doc2);

Should be allowed (but not compelled) to throw an exception.


XPathEvaluator.createExpression, createResult, evaluate, evaluateExpression

These names are too generic for methods that may be supported by the Document, since, as described at, certain bindings would have
difficulty if multiple interfaces supported by one object (in this case Document) had identically named methods.



Adapts ANY node...

Is accepting ANY node a little too permissive.  It wouldn't seem to make sense for DocumentType, Entity or Notation nodes.


XPathException code:

Following that thought, shouldn't there be a code for attempting to apply an XPath expression to an inappropriate context, like a DocumentType, Entity or Notation.


Section 1.2.1:

Some discussion should be added on using fragmented text nodes as context nodes in Xpath evaluation.  I would assume that using any of the actual nodes in a logical text node should be equivalent.


EntityReference nodes as context nodes

If an EntityReference only has one child (or its children are one logical text node), then it an evaluation on the entity reference could be equivalent to an evaluation on its child (or any of the
nodes in the logical text node).

However, if an entity reference contains multiple elements, then the evaluation doesn't correspond to any defined behavior in Xpath.

Received on Friday, 31 August 2001 14:14:13 UTC