W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2002

More DOM XPath comments

From: Jonas Sicking <sicking@bigfoot.com>
Date: Thu, 21 Feb 2002 15:17:23 +0100
Message-ID: <008301c1bae2$7b391bc0$b3e0d0d9@telia.com>
To: <www-dom@w3.org>

Reviewing an DOM XPath implementation by Peter Van der Beken (soon to be in
TransforMiiX and Mozilla) and comparing that to the spec has made me realize
a couple of more issues:

There should be some sort of exception that an implementation can throw if
the evaluation of an XPath expression fails, for example when evaluating:
"2/foo/bar" or "not(foo, bar)" or "false()[foo]". All of which are fully
parseable according to the set of productions in the XPath spec, but should
fail during evaluation.

I wrongly stated in a previous mail[1] that the returntype was undefined
when the requested type is ANY_TYPE and the XPath
expression results in a NodeSet. It has been pointed out to me that the
description for UNORDERED_NODE_ITERATOR_TYPE states that it is the default
type for that case.

First of all I would think that that would be better stated in the
description for ANY_TYPE since now you have to know the answer to find it
(or search though all resulttypes).

Second, it would be good if an implementation that knows that it will
produce a sorted nodeset can return that. For example TransforMiiX currently
always produces sorted nodesets, and most implementations will probably
always produce a sorted nodeset for the expressions like "foo".

So I suggest that implementations are allowed to return either
that don't care about sorting can always use the iterateNext() function,
whereas a user that needs the nodes ordered can do so manually if resultType

Jonas Sicking

[1] http://lists.w3.org/Archives/Public/www-dom/2002JanMar/0106.html issue 3
Received on Thursday, 21 February 2002 09:12:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:09 UTC