Some more suggestions and a DOM OM

I have a number of suggestions based on a relatively detailed review (and
implementation) of the DOM spec and influenced by recent postings to this
list. Probably the best way to communicate these suggestions is through a
class diagram (attached--my apologies in advance for the attachment, but it
is very small...)

- Transform Node into a very simple interface that has a parent Node (and
possibly a "validate" method).

- Comment and PI will be derived from Node (it may also make sense to create
an EmptyElement interface derived directly from Node).

- Create a new CompositeNode interface derived from Node with methods to
manage children. This includes indexed access, getFirstChild, getLastChild,
getNextSibling, getPrevSibling, removeChild, insertChild, appendChild,
replaceChild.

- Element, Entity, DocumentFragment, Text, and Attribute are derived from
CompositeNode.

- NodeIterator should have only getFirst, getNext, getPrev, getLast, and
release methods. Indexed access to children is supported by the
CompositeNode interface, not the NodeIterator interface. BTW, according to
the Iterator design pattern (gang-of-four), a ROBUST iterator won't make a
copy of the content of its data structure to get around problems with
insertions and deletions.

- Create a NodeDictionary interface to support lists of nodes keyed by name.
AttributeList could be derived from NodeDictionary (although it would be
more convenient if it didn't)

- Create a DOMException class. All DOM exceptions should be derived from
this class.  This is just a convenience mechanism, but many users won't
really care about WHICH exception is being thrown.

I threw in a couple of XML specific classes just to complicate things.

Whether anyone actually uses this diagram or not, a similar effort on the
final model would be very welcome I'm sure.

Jeff Mackay
Vtopia, Inc.
url: http://www.vtopia.com/
e-mail: jmackay@vtopia.com