Re: Call for unified tree model

In response to Nils posting:


> - LOST CHILDREN (DOM2):
> 
>   "Attr nodes are not actually child nodes of the element they
>   describe, the DOM does not consider them part of the document tree"
> 
>   So, attribute nodes are attached to their element node, but the
>   element node is not a parent.  The document tree doesn't represent
>   the document (but presumably, the "document hierarchy" does).

To me it looks pretty obscure to think of DOM in a way that every part of the
document tree should be a childNode of some other node.

It wouldn't make the concept extendible, because in the same logic you should
make any addition (of for instance meta-data) in future releases of Dom a
childNode.

To me it seems logic to have node structure which is a container for several
different information objects like children, attributes, infosets,
namespacenodes, persistency behaviour or any other future info object.

For me there is no natural fit which should make an attribute a childNode.

The fact that a Node object is used to handle generic features like going back
to the container (getParentNode()) doesn't mean that it should be a childNode.

> 
> - LOSING YOUR CHILDHOOD (XPATH): 
>  
>   "The element is the parent of each of these attribute nodes, but an
>   attribute node is not a child of its parent element"

I agree with you on this point. The getOwnerElement and getParentNode() issue is
confusing.


Jeroen van Rotterdam
The Connection Factory
www.tcf.nl
jeroen@tcf.nl

Received on Saturday, 29 January 2000 05:00:50 UTC