[DOMCore] Traversal

I suppose it is a good thing that the specifications for NodeIterator 
and TreeWalker are being tightened up, even though I'd prefer to just 
deprecate them :-)  Here's some general feedback about this new section 
of the spec:

1) I found that I was unable to make sense of the algorithms without 
refering to 
http://www.w3.org/TR/DOM-Level-2-Traversal-Range/traversal.html  §1.1 of 
the old Traversal spec actually seems quite good, at least to my casual 
reading.  Would you consider adding it to DOMCore as a non-normative 
overview at the beginning of the section? Without the overview, it is 
hard to figure out the difference between FILTER_REJECT and FILTER_SKIP, 
for example, and it is similarly hard to understand the point of 
pointerBeforeReferenceNode too.

2) Is the goal of this section to simply describe and standardize 
current implementations or to upgrade the functionality of these APIs?  
(Why, for example, did you add referenceNode and 
pointerBeforeReferenceNode to the NodeIterator API?) If the goal is to 
improve the Traversal APIs, how about adding constructors for NodeFilter 
and TreeWalker?   And if you do that, how about adding referenceNode and 
pointerBeforeReferenceNode arguments to the NodeFilter() constructor and 
a currentNode argument to the TreeWalker constructor.  Without those 
arguments, there is no way to clone the current state of a NodeFilter or 
TreeWalker without starting again at the root and iterating to the 
desired position.

3) The referenceNode/pointerBeforeReferenceNode pair seems like a 
complicated and ugly way to represent the state of a NodeFilter.  Is 
there any way to do better?  Could you at least change "pointer" to 
"cursor"?  Or, what if the state was instead represented by a pair of 
next and previous attributes, each of which was a Node or null?  These 
would be two adjacent nodes and the cursor position would be between 
them.  nextNode() would always return the next attribute and 
previousNode() would always return the previous attribute, but the 
methods would then adjust the cursor position. This would also give 
developers an option to peek at the next or previous node without moving 
the cursor.  I haven't tried to work the algorithms using next and 
previous as the state variables, but it I think that a next/previous 
pair carries the same information as 
referenceNode/pointerBeforeReferenceNode.  And my intuition tells me 
that the algorithms would be simpler when defined in terms of next/previous.

     David

Received on Friday, 29 July 2011 23:47:48 UTC