Comments on XPath DOM

Congratulations on the new DOM XPath draft, it's really taking shape into a
nice addition to the DOM family. I especially like changes to the
XPathResult interface.

I still have some issues, new and old, that i wanted to bring up:

1.
I'm really doubtfull that the gain of the |XPathResult result| argument to
XPathExpression::evaluate and XPathEvaluator::evaluate outwieght the
disadvantages.

Besides the obvious non-neatness of the extra argument I can see one big
problem: The fact that the implementation is free to not reuse the result
could be a source of interoperability problems. For example if one browser
don't reuse the result and a developer only tests his application in a
browser that does. (As pointed out by Curt Arnold in [1] it's still a needed
for to allow separate implementations for separate result-types).

The gain of reusing the implementing object seems rather small to me,
however that is agreeably very dependant of the implementation and the
implementation language.

2.
The wording for the result argument to XPathExpression::evaluate is wrong (I
hope). It should be the same as that for XPathEvaluator::evaluate.

3.
What is returned if the the requested type is ANY_TYPE and the XPath
expression results in a NodeSet? There are 4 possible "NodeSet types" in the
DOM XPath; order/unordered snapshot/iterator so it needs to be specified
which one should be returned. I can't really think of a "best" type to
return, while ordered snapshot is definitely the most convinient, there are
probably usecases where you both don't know the returntype but still need
speed.

I think that an ordered iterator would be a good tradeoff: most expressions
results in ordered expressions anyway, and in most cases you just want to
iterate once over the nodeset anyway.

A related convinience function could be an |XPathResult getSnapshot()| which
would create a new XPathResult out of an iterator. I can't really think of
any other usecases then if when ANY_TYPE returns an iterator and application
wants a snapshot.

4.
In the wording for FIRST_ORDERED_NODE_TYPE isn't quite right, the sentence
"If there are more than one node in the actual result, the single node
returned will be the first."
needs to mention that the returned node is the first _in document order_,
since XPath1.0 nodesets don't have any order and thus no "first" or "last".

5.
I think description for ANY_UNORDERED_NODE_TYPE and FIRST_ORDERED_NODE_TYPE
needs some clarification with regard to NodeSets that contains more then one
node. The sentence
"This is a convenience that permits optimization where the caller knows that
no more than one such node exists because evaluation can stop after finding
the one node of an expression that would otherwise return a node set"
sounds like it might be an error if the produced XPath NodeSet contains more
then one node.
(a similar sentence exists in the FIRST_ORDERED_NODE_TYPE description)

 I suggest something similar to:
"This is a convenience that permits optimization since the implementation
can stop evaluation once a single node in the resulting NodeSet is found"

6.
Many sentences like:
"Document modification does not invalidate the X, but may mean that the X no
longer corresponds to the current document"
sounds a bit wrong since the evaluation is dependant on both the document
and the context node. How about
"Document modification does not invalidate the X, but may mean reevaluation
would not yield the same X"


Regards,
Jonas Sicking

[1] http://lists.w3.org/Archives/Public/www-dom/2001OctDec/0059.html

Received on Friday, 8 February 2002 19:37:58 UTC