XOM API for Processing XML with Java

[Laurent Bihanic <laurent.bihanic AT atosorigin.com>]

Elliotte Rusty Harold wrote:
> Actually, you don't have to distinguish between containers and leaves when
>  navigating now. LeafNode is a subclass of TreeNode. TreeNode is a 
> subclass of Node. Most of the navigation methods (except getParent()) 
> are in TreeNode. LeafNode could go away without really affecting the 
> model at all. Currently it's effectively an implementation detail, not 
> part of the public API.

:-( If you get rid of LeafNode, you may end up adding a method such as 
isLeaf() in TreeNode.

> Mvoing to a single Node class is simpler. That's good. I originally 
> started with just the Node class, but then I decided that Attributes and 
> Namespaces needed to be distinguished from pieces of the tree. But then 
> I got rid of the Namespace class completely, so now the only 
> non-TreeNode node is an Attribute. That's not a very big benefit for 
> what amounts to a relatively large complexity.

What bothers me with TreeNode is that, in addition to navigation methods, it 
is full of append/insert/remove methods. Wouldn't be better to reverse the 
model so that Node includes the navigation methods (including child 
navigation) and TreeNode defines the append/insert/remove methods. With this 
model, Comments, PIs, Attributes and Text would be Nodes and only Element and 
Document be TreeNodes (BranchNode would be more appropriate then).

This would not change anything in the way to navigate the document tree. Extra 
typecasts would be required to adding/removing children but who cares since 
one has to test the node type before doing so or risk a runtime exception.

By the way, -1 for the one-size-fits-all Node class. DOM4J tries that and it's 
way too cluttered with methods that only apply to one or two classes.

Laurent