XOM API for Processing XML with Java

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

At 1:02 PM -0400 9/19/02, John Cowan wrote:
> The Javadoc on the site (which is all I am looking at just now, as I'm
> trying to do an architectural review) has an undocumented LeafNode class,
> which is the parent of DocType, Comment, ProcessingInstruction, and Text
> (and the child of TreeNode).  Presumably this is an attempt to abstract
> the idea of a node which is not a container.  What's the story here?

That's my laziness showing. :-)

LeafNode adds no new API. It simply implements about half a dozen 
methods like howManyChildren() with common code. For instance, 
howManyChildren() always returns zero for a leaf node.

If it proves confusing, it would be straight-forward enough to factor 
out those methods into the individual classes like Comment and Text, 
and remove it completely. The other way to go would be to expose it 
as public, which would allow tests of whether or not a particular 
node was a leaf node. I'm not sure if this is useful or not.

> FWIW, I think it would be better to have Node and a child Container
> whose children are Element and Document, and move the other stuff from
> TreeNode to Node.  It simplifies the architecture.


Could you be more specific about what would go where? Are you asking 
for Node --> ParentNode --> Element and Document, with other classes 
extending Node directly? Maybe that makes sense.

This is, however, possibly the first time in seven years I've 
actually regretted Java's lack of true multiple inheritance. I'd like 
to have separate ParentNode and ChildNode classes extending Node, 
with Document and Element subclassing ParentNode, Element also 
subclassing ChildNode, and the others just subclassing ChildNode. 
dom4j does this with interfaces, but I'm trying to stay away from 
interfaces.

On the other hand, having just the one TreeNode class does make tree 
walking a lot easier. There are no instanceof tests to distinguish 
between nodes and leaf nodes. That's sort of nice.

I could move some more stuff into Node. Most of the methods don't 
really make sense for attributes though. :-( getNextSibling() and 
getPreviousSibling() could be used for navigation from one attribute 
to the next. The child methods could behave pretty much the same as 
they do for leaf nodes. Maybe that makes sense.
--

+-----------------------+------------------------+-------------------+
| 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/    |
+----------------------------------+---------------------------------+