Comments on first read of DOM

I have maintained a product based on a document object model in Java
extremely similar to DOM (several methods and names are identical) and
have reviewed the specification and have some comments, but in general,
I
like it very much.  Perhaps I should have put these into seperate
messages
for easier discussion.  I boldly comment, and suggest corrections and
enhancements, while realizing that I am not in the same position as a w3

member might be to expect the suggestions to be carefully considered.
I have had these comments reviewed by others knowledgeable in the
DOM-like architectures, but they could still could easily contain silly
misunderstandings, but here goes:

1.  The object descriptions describe a Node method called
"getFirstChild", which is missing from the IDL and Java specifications.
There should also probably be a "getLastChild".  In most cases for
general traversal, these make it easier to traverse sets of siblings
from
either direction than getting a child list and then getting children out
of
the child list.

2.  It is very convenient to be able to process children without keeping

track of indices (which could even be hard to predict in a large
changing set of siblings).  getFirstChild, getLastChild, getNextSibling,

getPreviousSibling, getParentNode, all make this possible.  But
unfortunately, the insertion, removal, or replacing of siblings or
children suddenly forces the inserter or remover to be aware of the
current index number, which may be unknown.  At the very least, a
method getSiblingIndex() would make this process much easier.  Even
better, might be a remove/replace call that accepted just the node to
be removed/replaced instead of its index, and an insertBefore and an
insertAfter call that allowed you to insert before or after an arbitrary

node.  I believe this is easily implementable even if the node objects
are aliases (see 3. below).

3.  The uniqueness of object identity should be made clear.  Since these

are interfaces that may be aliases created to access the real objects,
two
calls to query the same object could return different objects, i.e. if
you
have a next sibling, this.getNextSibling().getPreviousSibling() might
not
be guaranteed to be == this, but it would be functionally equivalent,
and
perhaps a function would be useful to show that two nodes are actually
the same node.  If two aliases which represent the same node must always

be the same object, (that can also be implemented with more difficulty
because aliases must be tracked and not simply garbage collected) then
that could be clearly stated in the specification.

4.  In the description of the Node method called "getChildren", it says
that on the one hand, if there are no children, a null is returned, but
otherwise the node list is "live" so it may dynamically reflect changes.

It seems to me that since it is live, it would be more consistent to
return an empty list in the case of no children instead of returning
null,
since the list is a live one even if empty.  The "hasChildren" method
will allow this case to be easily avoided where this live update is not
important to the applicaion.  The issue of live update should be made
clear throughout the specification -- especially in enumerations.  I
suspect that my own implementation of the specification would allow a
constant document to be gotten for those extended operations that should

never modify the document and require consistency over an extended
period of time.

5.  The issue of case sensitivity is first raised, and then the burden
is placed on the application writer, but in the case of
getElementsByTagName or any future query mechanism, the DOM
implementation must be aware of case sensetivity or insensetivity.

6.  I would assume from the specification, but it is not clearly stated,

that white space which may be ignorable which is ajacent to
non-whitespace would create distinct ajacent text nodes.  This seems a
bit confused between different descriptions in the specification whether

the whitespace flag says ignore any whitespace that happens to be
leading/trailing here, or this whole text may be ignored.

7.  It might be useful to clarify  the expected behavior of traversal
and other methods of a node and its children which has been removed from

the document root, but not reinserted.

8.  Instead of making explicit setters/getters on Document for the root
node and the type node, it might be more general to have a simple
getNamedNode/setNamedNode with standard names for the default type
root, the default document root (using a NamedNodeList underneath).
Of course, the more general routine could always be added later when it
becomes clear (as it already is to me) that multiple arbitrary named
roots are very useful without hurting the existing more-explicit
accessors.

I can hardly wait for the specification to become the accepted standard!

Ray Whitmer
raywhitmer@itsnet.com

Received on Friday, 17 October 1997 00:10:36 UTC