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

Re: Walking the DOM (was: XML APIs)

From: Ray Whitmer <ray@imall.com>
Date: Mon, 09 Nov 1998 08:42:25 -0700
Message-ID: <36470D61.4CCE1F01@imall.com>
To: DOM List <www-dom@w3.org>
Stephen R. Savitzky wrote:

> I think it is possible to accomodate both kinds of programmers by explicitly
> specifying all three kinds of iterators: efficient and straightforward,
> careful (robust against deletion), and paranoid (throw exception on any
> modification).  If a choice has to be made, though, I would opt for
> efficient and straightforward on the grounds that those are the ones that
> are going to be _used_ anyway, whether or not the DOM specifies them.

I think I like the idea of allowing the programmer to choose between an iterator
which is safe during deletions (insertions, etc.) and one which self-destructs.  The
techniques available to implement the fixups of either choice are not too different
from how you would fixup the current live node list in the specification, for which
there are a variety of efficient solutions.  By choosing, the use case can guide the
fixup effort better, at the expense of a more complex API and implementation.

But I suspect you are confusing "efficient and straitforward" with "nearly redundant
with that already provided in the API via node-to-node navigation", such that state
could be maintained by holding a reference to an API node.  To accomplish this type
of node-to-node navigation (which isn't even useful for many use cases) API nodes
must carry or generate extra, redundant, and limiting state.  So don't assume this
is THE efficient choice, or THE straitforward one.  It employs one aspect of the
existing node API.  Others could be built on other aspects.

Had there been a single universally "efficient and straitforward" choice, it would
have been made long ago.  In my own implementation, "efficient and straitforward" is
a fairly good description of the implementation of the nodelist used to access child
lists, and an iterator would be built on that.  Others disagree.  Implementations
can support aspects of APIs well and fairly efficiently which are not native to
their representation, but you pay something for this interoperability.  Some may
think there is a single underlying representation that beats all others on the
server for all important use cases and therefore should be declared as the single
"efficient and straitforward" choice for servers, but I think they have an uphill
religious argument to make, too.

Just because I am unwilling to proclaim a single choice to be THE "efficient and
straitforward" choice, does not mean I am not willing to think about supporting yet
another model for dealing with liveness.  If I were to guess at what you intended, I
suspect it would be based upon node-to-node navigation.  Perhaps you could describe
the behavior more accurately than calling it the "efficient and straitforward"
choice so we could discuss it.

The other choices should be nailed down more accurately, too.  Exactly what is the
robust case robust against, and how does this robustness respond in a variety of
cases, and in exactly which situations does the paranoid case self destruct?  I
would like robust to be completely robust, with respect to the node from which the
iterator was originally requested, even surviving in this original hierarchy during
the removal of intervening ancestors.  I would also like paranoid to be at least
intelligent enough to only destruct when a descendant of the node where the iterator
was constructed was inserted or removed.

We are all trying to get the best efficiency we can out of an interoperable
specification.  But a proprietary interface or arrangement with the implementation
will always beat a portable API.  IMO, so if someone is not willing to sacrifice
something in performance, they should drop interoperability as a goal, and probably
drop XML, too.  Binary files are faster to process.  Interoperability seems to
usually involve paying a price for requirements, many of which any particular case
doesn't consider important.

Ray Whitmer
ray@imall.com
Received on Monday, 9 November 1998 10:43:08 GMT

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