- From: Elliotte Rusty Harold <elharo@metalab.unc.edu>
- Date: Fri, 15 Feb 2002 23:49:52 -0500
- To: rayw@netscape.com (Ray Whitmer)
- Cc: www-dom@w3.org
At 6:13 PM -0800 2/15/02, Ray Whitmer wrote: >All implementations thus far have an easy way of grabbing just a >single result without caring about complete computation of the >result. This is an extremely practical consideration both for ease >of use and for efficiency of use and implementation. When the >caller needs just one, he shouldn't have to set up the whole >mechanism required for dealing with multiples. Ultimately, XPath >and DOM are for the use of the user. It is common to need just one >node, which is what the API makes easily available, but only if that >is what was requested. > That's not quite true, at least not as I read the API. The user may write an XPath expression which returns a node set containing 10 nodes. However, the current API presents this just the same as an XPath that returns a node set containing one node. I wouldn't mind a selectSingleNode() function provided it threw an exception if the XPath produced anything more or less than one node. The API should be as simple and easy-to-use as possible, but no simpler. There's been a real tendency in XML APIs to hide the complexity of XML by pretending it's simpler than it really is. This isn't a good thing. Fortunately, this is a sin which DOM hasn't committed to date. (In fact, I suspect the opposite is true if anything.) The fact is XPath 1.0 expressions do not return single nodes. They return node sets. I see lots of developers making logic errors because they think an XPath expression returns a single node. It might be easier for them if an XPath expression did return a single node, but this isn't what actually happens and it isn't something that can be fixed in DOM. It would have to be fixed in XPath. DOM should not sweep the issue under the rug. It should allow developers to ignore the very real possibility that an expression returns several nodes. In the long run, I suspect we'd all be better off if DOM XPath hewed more closely to what XPath actually is, rather than what developers want it to be. -- +-----------------------+------------------------+-------------------+ | Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer | +-----------------------+------------------------+-------------------+ | The XML Bible, 2nd Edition (Hungry Minds, 2001) | | http://www.ibiblio.org/xml/books/bible2/ | | http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ | +----------------------------------+---------------------------------+ | Read Cafe au Lait for Java News: http://www.cafeaulait.org/ | | Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/ | +----------------------------------+---------------------------------+
Received on Friday, 15 February 2002 23:52:34 UTC