Re: XPathResult singleNodeValue

Thanks for the comments.  The more we work through different possible 
choices, the stronger we tend to feel about what we have.

Elliotte Rusty Harold wrote:

> The singleNodeValue attribute in XPathResult bothers me.
>
> readonly attribute Node singleNodeValue 
> <http://www.w3.org/TR/DOM-Level-3-XPath/xpath.html#XPathResult-singleNodeValue>; 
>

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.

> I'm afraid that this is going to encourage developers to assume that 
> there's exactly one result when in fact that may not be true. I think 
> I'd prefer this attribute to return either NodeList or some custom 
> XPathNodeSet interface and put all the iteration methods in that 
> interface, rather than directly in XPathResult. e.g.

The names and descriptions of the single-node type make it clear, I 
believe, that although the XPath result may easily contain more, the 
user gets what he requested (although if you can suggest how to make it 
clearer, please do so).  If you ask for one, you get one back, which is 
any unordered node of the result or the first ordered node of the 
result.  If ask to iterate over the result on the live tree , that is 
what you get.  If you want a snapshot that does not invalidate, that is 
what you get.  Users seem to understand the concept of an iterator that 
invalidates when the thing it is iterating over changes, as well as a 
"snapshot".  I think the confusion has been less since the terminology 
has changed to be more relevant.

There are significant issues of liveness and consistency that DOM 
implementers and users cannot simply ignore, however much they may be 
ignored in XSL and other XPath situations.  Returning a NodeList would 
give people the wrong guarantee about liveness because of the clear 
guarantee of DOM with respect to liveness of NodeLists.  Calling it a 
"Set" clarifies nothing about how it is different from a NodeList, but 
just gives users another interface to confuse.  The live behavior of a 
NodeList is quite appropriate for a child list, but much less so for the 
result of an XPath query.  XPath followed quite different assumptions 
from the existing DOM model, and in more ways than just liveness.  I 
think the interface is a reasonable API for making the results of XPath 
1.0 expressions available in DOM.  It supports by request multiple views 
of the XPath result, as is useful to DOM users, and directly on the 
returned object, which seems to make it simpler for users than juggling 
multiple result objects and getting one from the other.

A set is not inherently a list, but if you wish to access it as a list, 
then use the snapshot because lists of things computed like XPath 
results have difficulty being live.  I think if you think the static 
list is your preferred form, then ignore everything but the snapshot, 
and write all your examples and use cases accordingly.  But DOM needs to 
satisfy other use cases.  As much as DOM has been ignored by XPath 
purists, I think percieved purity in the DOM implementation of XPath 
(which I don't agree that your suggestions accomplish) would not win out 
over the ability to practically use the interface to get the desired 
results.  We would have returned variant object types for better 
conceptual separation instead of a single result, but that is not easily 
supported in all target environments, and there is no difference in how 
the user uses it.  The one object is effectively multiple object types 
simultaneously.  It does not seem to help the user to force him to 
juggle more distinct objects for every query.

> readonly attribute NodeList nodeSetValue 
> <http://www.w3.org/TR/DOM-Level-3-XPath/xpath.html#XPathResult-singleNodeValue>; 
>
>
>
> This model just feels to me to be a lot closer to what XPath 1.0 
> actually states. For myself, I noticed that I didn't really understand 
> XPath until  learned to stop thinking in terms of single nodes and 
> start thinking in terms of node sets.

I do not believe any implementor is willing to implement a live XPath 
implementation, as your use of NodeList requires.  XPath does not 
mention NodeList, whereas it is a clear concept in DOM, and one that 
does not apply in this case.  The current API is a very practical 
bridge, I think between XPath results and DOM access to them, and it is 
not like we have not seriously entertained each alternative you mention.

Is there anything that the current API does not do that you need it to?

Ray Whitmer
rayw@netscape.com

Received on Friday, 15 February 2002 21:14:21 UTC