- From: Dominic Chambers <dominic.chambers@bigfoot.com>
- Date: Tue, 29 Oct 2002 21:11:20 -0500 (EST)
- To: <www-dom@w3.org>
- Message-ID: <004101c27fb9$632b13c0$0100a8c0@hp>
I have been using Mozilla 1.1 to experiment with the XPath module, and there are a number of things that don't feel quite right about it: 1. XPathEvaluator should be implemented by objects that currently implement Node, not Document, since you need to have the context node anyway, and node.evaluate(expr), is cleaner and more OO than document.evalute(expr, node). 2. The resolver, type, and attributes should be made optional for the ECMAScript binding, since almost nobody will ever use them, and instead just pass nulls anyway. This may seem trivial, but the majority of users favour simplicity over complexity. Everyone will be deeply impressed when they need more power to find that it exists, but it should appear really simple to start with. For example: document.evaluate("foo/bar", node, null, null, null) does not have the finnesse of: node.evaluate("foo/bar") I noticed that the group are worried about naming clashes, but since Document extends Node, moving the interface to that object would decrease the chance of a name clash. The Microsoft selectNodes and selectSingleNode functions were just about right, only lacking the ability to compile expressions, provide your own functions, or specify that ordering is unimportant. Since it is a trivial task for XPath implementors to compile and index all expressions internally, and since this spec provides no means to provide your own functions, I wonder what all this complexity is really buying us. I can already see the article that, in a grandiose manner, shows people how to fix these problems and provide selectNodes, and selectSingleNodes functions with automatic internal compilation in just a handful of lines of JavaScript. Maybe I should just get it over with, and write it myself. Regards, Dominic.
Received on Thursday, 31 October 2002 09:31:46 UTC