Re: Document Object Model (DOM) Level 3 XPath Specification

Curt Arnold wrote:

>Ray Whitmer (>) and Bob Foster (>>) wrote:
>
>>further feedback).  We are talking about the actual DOM nodes returned
>>from an xpath expression, and what to do when XPath says there should be
>>a single node, having discarded information, but DOM has fragmented it
>>across multiple nodes.  Answer: in case of fragmentation, return just
>>the first node.
>>
>
>That doesn't sound good.  If I have a text content, I don't want to get
>partial
>information if the implementation doesn't expand entity references.  I'd
>would think
>an object that exposes the appropriate interfaces (say CharacterData and
>Node) but represents the underlying node list and that pseudo-node could
>be used to update the content or remove the entire set.  If I set the value
>of the pseudo-node, then all the existing text and entity references would
>be replaced.
>
If it implements CharacterData, then what does parentNode point to? 
 Some node that it is not a child of, or do we clone the whole tree, and 
have no way to reference the real nodes?  I think that you cannot create 
a coherent pseudo-fragment of the tree without recreating a whole 
separate tree and losing correlation to the real nodes you were 
interested in.

What we chose to do is return a real node of the tree, that DOES 
implement CharacterData but is admittedly only the first node.  The user 
can use the methods getWholeText or replaceWholeText to manipulate the 
surrounding nodes as though they were a single virtual node.  There is 
no shame in the fact that the models simply cannot match perfectly.

>I think it is necessary that there is a generic evaluateAs(), however I
>don't think it is necessary or desirable to pass the type as an argument
>since XPath 2.0 should have the Schema datatype equivalents of
>string(), number(), etc.  The evaluteAsString, evaluateAsNumber,
>etc are useful and probably should be kept.
>
What object type would the calling application expect to be returned? 
 As I understand XPath 2.0, data type is determined not by the XPath 
expression but by the value space of the actual value, and a return type 
may simultaneously be instance of multiple types.  The purpose of the 
passed-in argument is to tell what object type we need back.  If the 
languages used to implement DOM applications were as untyped as Lisp, 
which seems to be the inspiration for XPath 2.0, then we might not need 
to tell it what type we needed.  But we need to be able to say what type 
we need in the program.  Otherwise, we will have no idea what is being 
returned or how to use it.

>I mentioned that I think NodeSetIterator and NodeSet are better names for
>ActiveNodeSet
>and StaticNodeSet.  ActiveNodeSet behaves like an fail-fast iterator on a
>collection.  StaticNodeSet behaves like a common ancestor to NodeList and
>NamedNodeMap.
>
The methods of these interfaces have changed a bit since I started, so I 
would not be opposed to renameing them appropriately.  I agree that 
ActiveNodeSet behaves like a fail-fast iterator.  But I would be afraid 
of confusion if we called the one type an iterator of the other, when it 
is not.  The ActiveNodeSet does not iterate across the StaticNodeSet, 
but rather across an active result set.  A StaticNodeSet snapshots a 
list of the nodes in the ActiveNodeSet.  While the names might make 
sense in isolation, together they seem quite misleading.  I would be 
more inclined to try something like NodeSetIterator and NodeSetSnapshot.

Ray Whitmer
rayw@netscape.com

Received on Friday, 29 June 2001 19:33:38 UTC