W3C home > Mailing lists > Public > www-dom@w3.org > October to December 1998

Re: Walking the DOM (was: XML APIs)

From: <keshlam@us.ibm.com>
Date: Tue, 3 Nov 1998 15:53:52 -0500
To: www-dom@w3.org
Message-ID: <852566B1.007212B3.00@us.ibm.com>
>An iterator that has to take structural changes into account _cannot_ be
so
>compiled

Depends on what we mean by "take into account". If it can be expressed as
just one localized test -- "Has the iterator's reference/current node been
altered/relocated since we last looked at it", exact definition still to be
hammered out -- the iterator's structure, whether recursive or iterative,
need not change beyond throwing an exception if that test fails. That
shouldn't interfere with a compiler's ability to recognize and unwind
tail-recursion.

Doing this test efficiently is a trifle ugly -- you get into questions of
how much should be computed locally and how much should be flags set when
the tree was actually altered -- but I don't think I agree with your flat
assertion that it can't be done.

I don't much care whether iterators could be used as the basis for live
NodeList or not. It would be nice if they could, to minimize redundant
code, but I refuse to let NodeList drive iterators -- and it's too late for
iterators to drive NodeList.

>I believe it is also essential that DOM implementations make structural
>_modification_ methods fast

In principle I agree, but in practice this depends on what the
implementation is being used for. We may wind up with implementations tuned
for various points on various axes (speed if read-only, speed when edited,
speed when edited but with NodeList not a concern; code size, model size,
gods know what) competing against each other in the marketplace. That is
not necessarily a bad thing. The spec makes no performance promises; that's
left to quality-of-implementation... and quality is defined by how well an
implementation meets the needs of each individual user.

If you can't find an implementation that meets your needs, you may have to
write a better one. If you can't do that either, you may in fact find
yourself forced to abandon the DOM. No silver bullets, folks; the DOM is
just one solution, and I expect that sometimes the needs of a particular
application _will_ dominate over interoperability and the DOM will
occasionally lose the race. But If it's only adopted in 90% of the
potential applications, that's still a big win.
______________________________________
Joe Kesselman  / IBM Research
Unless stated otherwise, all opinions are solely those of the author.
Received on Tuesday, 3 November 1998 15:54:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:46 GMT