- From: Jonas Sicking <sicking@bigfoot.com>
- Date: Thu, 21 Feb 2002 15:17:23 +0100
- To: <www-dom@w3.org>
Hi, 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: 1. 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. 2. 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 UNORDERED_NODE_ITERATOR_TYPE or ORDERED_NODE_ITERATOR_TYPE. That way a user 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 is UNORDERED_NODE_ITERATOR_TYPE. Regards, 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