XOM API for Processing XML with Java

[Elliotte Rusty Harold <elharo AT metalab.unc.edu>]

At 2:36 PM -0400 9/19/02, John Cowan wrote:


> I think it does make sense to put the navigation in Node.  It's an open
> question, IMHO, whether sibling navigation makes sense for Attributes,
> but the *methods* make sense: it's just whether they should return another
> Attribute in the list or else null.

I'll have to look at the code to remind myself of how this is going 
to affect the implementation. I think internally I depend pretty 
deeply on the difference between Node and TreeNode. It certainly can 
be fixed. It's just that this may not be as quick as changing 
howmanyChildren() to getChildCount()

> That way you don't have to distinguish between containers and leaves when
> just navigating, and Container is the proper home of addChild, getChildren,
> and all those mutators.

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.

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.

You know, I wonder? Does Attribute deserve to be a Node at all? Would 
anything be lost if Attribute did not extend Node? It could still 
have all the methods. You just wouldn't be able to pass it to a 
function that expected a Node object.

Actually, I do know what this would screw up. It would be a royal 
pain for XPath, because location paths can return a node list that 
may contain elements, attributes, or both. If we don't make Attribute 
a subclass of Node, then we'll be back in the JDOM-world of lists of 
objects. Yuck. So Attribute has to be a Node.  The question remains, 
is it worth distinguishing between Attribute nodes and all other 
nodes?

One advantage to not distinguishing (everything is a Node): when we 
do implement XPath then we can do more useful things with the 
contents of the NodeList the location path returns without casting, 
because the Node class has more methods.
--

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo AT metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|          XML in a  Nutshell, 2nd Edition (O'Reilly, 2002)          |
|              http://www.cafeconleche.org/books/xian2/              |
|  http://www.amazon.com/exec/obidos/ISBN%3D0596002920/cafeaulaitA/  |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
+----------------------------------+---------------------------------+