DOM Level 2 Spec: Iterators

Reading this I have an observation.
I like the behaviour described by the iterators, but I think there is an
easier model of this behaviour if you allow nulls, and an end-of-list
condition/marker.  The document itself points out one difficulty that can
easily be overcome by the new explanation.

<quote>
(ED: The fix-ups required by this model complicate implementation somewhat,
but make life simpler for the user of iterators. Much of the
complexity of fix-ups is in notification - the fix-ups themselves are then
relatively straightforward. It might seem simpler to invalidate an
iterator when changes are made, but invalidation also requires
notification. We currently feel that handling change gracefully is worth
the
added implementation cost, but are interested in feedback on this issue.)
</quote>

A second difficulty is missed in the statement:
<quote>
Note that the relative position of the iterator is not the same as the
absolute position within the set. The position of the iterator is relative
to the node before it and the node after it......
</quote>

This is simplistic.  The position cannot always be relative to BOTH the
preceeding AND the succeeding nodes, since one may move with respect to
other.  There needs to be an order of precedence. Your examples show one
such case, and the preceeding node seems to take precedence.   I think if
you try to codify the rules you will find it complex.  I have tried to do
this at the end of the note with an example titled AMBIGUITY.

A simple model for the behaviour may be to regard the traversal as being
across a (potentially infinite) ector that can contain null (?) entries.
These are ignored in iteration.  I put my interpretation under yours in the
copied text that follows.  relative position is an asterisk, nulls are
question marks.  I do not know how style and colour get translated so I
have included my bits in pseudo tags .

I am not claming to in any way 'right' as opposed to the proposal being
'wrong'.  I am make a suggestion, and I hope it reads ike that.

<quote>
Using ordered set semantics, the position of the iterator is determined by
the relative position in the ordered set. There is no current node. When an
iterator is created for a list, the position is set before the first
element:


* A B C D E F G H I
<comment>
*A B C D E F G H I
</comment>


Each call to next() returns a node and advances the position. For instance,
if we start with the above position, the first call to next() returns "A"
and
advances the iterator:


 A *B C D E F G H I
<comment>
A *B C D E F G H I))
</comment>

The relative position of the iterator remains valid when nodes are deleted.
Suppose the nodes in our list do not come from a tree, but are merely a set
of nodes in which none of the nodes are children of other nodes. If you
delete "A", the position of the iterator is unchanged with respect to the
remaining nodes:


* B C D E F G H I
 <comment>
?*B C D E F G H I          -B is next to be iterated
</comment>

Similarly, if "B" and "C" are deleted, the position remains unchanged with
respect to the remaining nodes:

* D E F G H I
<comment>
?*? ? D E F G H I
Here the iterator will skip any null entries giving the same result as the
proposal))
</comment>

Moving the "D" node to the end of the set does not change the current
position:

* E F G H I D
<comment>
This an intuitive result, but may be easier to explain as follows: first
remove 'D'
? ? ?*? E F G H I
then append 'D' to the end of the list
? ? ?*? E F G H I D
this would require an extensible list, and therefore an end-of-list marker
or a changeing number-of-entries counter.
</comment>

</quote>




AMBIGUITY

To return to the consideration of precedence of pre- and succeeding node
movements in determine the new relative position:
Consider the sequence:
A B C D*E F G H I J
What if we move E to the front?  Probably
E A B C D* F G H I J
What if we move 'F G' to the front?  Probably
F G E A B C D*H I J
What if we move 'H I J' to the front?  Probably
H I J F G E A B C D*
So we assume that however many we move from after the insertion point, the
insertion point does not 'move' from being after the preceeding node.  So
if we start from the alphabetically ordered sequence:
A B C D*E F G H I J
and move 'E F G H I J'
to the front we get
E F G H I J A B C D*



Lets start again
A B C D*E F G H I J
What if we move 'A B' to the end? probably
C D*E F G H I J  A B
What if we moved 'C D' to the end? probably
*E F G H I J  A B C D
So we could move d start with
A B C D*E F G H I J
and move 'A B C D' to the end and get
*E F G H I J  A B C D

So there is a difference between moving A B C D' to the end and moving 'E F
G H I J' to the front.


Phill van Leersum                        ________________________
___________________                      MQSeries Development
phillvl@ibm.uk.com                       mp206 Hursley Park,
Tel +44-1962-815167                      Winchester,
                                   Hampshire SO21 2JN.

Received on Monday, 17 May 1999 08:16:16 UTC