Re: Question about getNextSibling/getPreviou

At 09:48 AM 3/9/98 -0500, akirkpatrick@ims-global.com wrote:
>Am I right in thinking that these methods are going to be
>very inefficient? Assuming a child node has no prior knowledge
>of the previous/next nodes in the tree, all it can do is:
>
>1. Get its parent node
>2. Get the children of the parent node
>3. Run through the list to find itself
>4. Return the previous/next as applicable
>
>The only way this could be improved is by adding next/previous
>pointers to each node which will a) increase memory use and
>b) make editing the tree very tedious. Also, given the current
>DOM, there are no methods for setting the previous/next so this
>approach isn't possible.
>
>Have I understood this correctly?

Remember that the DOM is an *interface* (in the Java sense, or in the sense
of a C++ abstract base class), not a data structure.  I agree that a data
structure with next/previous pointers would make the getNext/getPrevious
siblings much more efficient to implement than the basic "structure model"
exposed by the DOM, but we want the DOM to be as "thin" as possible and as
compatible with multiple implementations as possible.  [By
"implementation", we mean "a product that supports the DOM as an API",
e.g., one of the HTML and/or XML browsers,  HTML and/or XML editors,
document management systems, publication systems, etc.]

For example, one implementation might use a tree of multiply-linked lists;
another might use an array of arrays.  However one navigates the native
data structures, we want convenient, standardized DOM methods to work.  So
one implementation of getNextSibling might navigate via a Next pointer,
another might increment an array index; either would be efficient in that
implementation, but specifying too much implementation detail does not help
achieve the goals of the DOM.

Is that clearer? 

One more point (that may or may not be a digression):  The DOM's primary
goal is to promote INTEROPERABILITY, not efficiency.  Assuming, for
example, that both Microsoft and Netscape support the DOM someday in their
browsers, the idea is that one can write a script, JavaBean, etc. that
works with both.  It may be that some approach is far more efficient in
implementation one than another, and the vendor is free to steer the DOM
programmer toward the more efficient approach on their particular
implementation (and of course the other vendor could steer the DOM
programmer toward a different approach).  Yet we'll consider the DOM a
success if the script/Bean/control WORKS on both even if it works BETTER on
one or the other.

>
>Also, can I reiterate the call for a new draft. It sounds from
>recent emails that major changes are afoot and it would be
>nice to get them in before people in our wider organisation
>start using the code I've been writing.

We hope to have public draft out in the next 10 days.  I'm sorry this
process is taking longer than we hoped, but I for one am convinced that the
current draft is quite a bit cleaner, leaner, and meaner than its
predecessors; I hope that you find your patience rewarded!


Mike Champion

Received on Monday, 9 March 1998 10:23:15 UTC