Re: NodeIterators & Java implementation

At 02:35 PM 5/6/98 -0400, Michael Amster wrote:

>First, without Node locking semantics in DOM, the idea of maintaining a
>synchronized tree to readers and writers looks very difficult to me.  That
>the NodeIterator should be robust enough to take an insertion or deletion
>of children is given, but the results in a greater sense are not clear to me

I don't understand what's not clear -- could you ask a more specific question?
I'm also not sure how locking semantics would help; they would help two DOM
writers keep from making a mess out of things, but even with one DOM writer
the NodeIterators need to reflect changes to the tree.

>
>I'd also like to examine the cost of some of these operations (in Java) as
>Don Parks mentioned.  Java has a high cost of object instantiation, so
>object reuse is paramount to a good implementation (again, I am working on
>the Server side so we are talking about large numbers of DOM nodes and
>users).  The use of NodeIterator for both Attributes and child nodes is
>expensive in Java where an iterator will be instantiated for examining the
>Attributes and for examining the Child nodes.

Are you suggesting that there be a way of creating (or re-initializing) a
NodeIterator so that it can enumerate the Attributes, and then the children
(or vice versa)?  That's an interesting idea that the API currently has no
way to allow ... But my off-the-cuff answer is that it seems like more of
an implementation matter than an API matter; I mean, there's no demand that
getChildNodes or whaterver return a NEW Java object if an already created
one can be re-initialized to traverse a Node's children ... What API change
would you suggest?

>
>My feeling is that we should make the common things fast.  If DOM trees are
>built, my assumption is that readers/users will outnumber writers/producers
>so that the reference operations need to be faster than the building
>operations.

Another implementation issue?  Maybe this point doesn't need
re-emphasizing, but remember that the DOM is an ABSTRACT INTERFACE design,
not a DATA STRUCTURE design; implementations can do whatever they need to
do to be efficient within the DOM API's constraints.  Again, can you
suggest an API change that would help?

>
>In AttributeList where order is not important (at least not in XML), it
>seems like a waste to use the NodeIterator, 

[snip]

>What is the issue for using NodeIterator for AttributeList?  Is it because
>it is already defined conveniently?  Is it so that Entity References can be
>represented (thereby using Node rather than a simpler object for Attribute)?

Both.  In XML, attribute values can be entity references, so things can get
complicated, so we wanted to re-use the Node stuff.

BUT you have lots of company in questioning the efficiency of using
NodeIterators in situations where most people would want a  simple
Collection or associative array.  This is under active discussion on the
WG... If I have time I'll post a message laying out some of the issues and
asking for opinions on how to handle some of the dilemmas we face.

Mike Champion

Received on Wednesday, 6 May 1998 15:47:43 UTC