Re: Some more suggestions and a DOM OM

>> > - Transform Node into a very simple interface that has a parent Node
(and
>> possibly a "validate" method).
>
>validate() seem like an implementation specific issue that should not be in
>the interface specification IMO.

That may be true, although most implementations will need a validation hook.
I just wanted to get some discussion started on the topic...  There was a
request for an InvalidChildException (or something to that effect) on
insertChild().   I believe that would unnecessarily complicate the building
and processing of simple documents. But since all conforming processors have
to do validation at some level, it makes sense that validation should be
available through the DOM--whether through the Node interface or the
Document interface.

>
>> - 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.
>>
>> - Comment and PI will be derived from Node (it may also make sense to
create
>> an EmptyElement interface derived directly from Node).
>>
>> - Element, Entity, DocumentFragment, Text, and Attribute are derived from
>> CompositeNode.
>
>This is very similar to David Brownell's proposal for DocumentFragment.
>Why is Text derived from your CompositeNode?  And hasn't Attribute been
>changed so it is not a subclass of Node?

Oops.  Attribute shouldn't be derived from CompositeNode.

Received on Sunday, 3 May 1998 17:50:45 UTC