Re: Comment on DOM Level 2 § 6.1.3.

Dieter Köhler wrote:
> 
> >
> > Applying this notion to Dieter Köhler's example below, parentNode
> > returns 'A'.
> >
> > Any comments?
> >
> 
> It seems to me a more natural behaviour when any in some way critical
> modification of the DOM-tree is answered by invalidating the Treewalker
> or by re-initializing it (setting it to 'root' or to the node "above"
> the modification), because otherwise the TreeWalker.current is working
> in a branch of the tree that "normally" would have been ignored.  So a
> TreeWalker must allways pay attention to modifications that appear
> between (including) the 'root' and the 'current' node, and not only to
> those immediately before or behind the 'current' node.  The problem is
> then: How should that be implemented? By events? By visitors?
> 
> For reasons of performance I would suggest adding a flag to the
> TreeWalker interface which specifies whether at all the TreeWalker keeps
> an eye on modifications.  If one knows, that her application needs a
> TreeWalker only to traverse a stable DOM tree or that the TreeWalker is
> not affected by potential modifications then she can use this flag to
> increase the performance of the application.

IMO, the difference in behavior between a TreeWalker that responds to
changes in a Document versus one that continues on regardless of changes
is better represented by different subclasses of TreeWalker, instead of
toggling the behavior with a flag.  Similar to how (some|most?) XML APIs
have different subclasses for validating and non-validation parser.  If
implemented with events, then the latter TreeWalker either ignore the
event or just not register itself as a Listener.  I see that as
sufficiently flexible to design for performance in the cases where you
can ignore changes.

However, the original question of what is the "natural" behavior of a
TreeWalker that does respond to a changing Document is still a good one
(to me).  I'm assuming that it is a goal of the WG to specify this type
of behavior unambigously so that we don't end up with incompatible
implemenations, but maybe I misunderstand the purpose.

Tim


> 
> Note on my posting "Comment on DOM 2", date Wed, 01 Sep 1999, section
> 'COMMENT ON § 6.2. b'": Instead of "What about a LastNode and a
> PreviousNode method?" read "What about a LastNode method?"
> 
> =====================================================================
>  Dieter Koehler, M. A. - dkoehler@ix.urz.uni-heidelberg.de
>  Huehnerstein 1, D-69121 Heidelberg, +49(0)6221-474359
>  "http://www.philo.de/Philosophie-Seiten": 1000+ Philosophie-Links
>  "http://www.philo.de/VirtualLibrary/14.de.htm": Deutsche Philo-Links
>  "http://www.philo.de/xml": Open XML - XML-Komponenten fuer Delphi
> =====================================================================

-- 
Tim Taylor                

If both of us agree, one of us is unnecessary

Received on Tuesday, 7 September 1999 12:32:26 UTC