[jdom-interest] The JDOM Model, Chapter 15 of Processing XML with Java

[Laurent Bihanic]

Elliotte Rusty Harold wrote:
> Unfortunately, JDOM never really had an equally compelling XML vision. 
> This has led to a lot of weirdness and unanswered questions like:
> 
> 1. What is a node?

Here's an excerpt of the last mail exchange I had with Jason on this subject: 
This proposal primarily aims at making walking the JDOM document tree up and 
down simpler.

Laurent Bihanic wrote:
 > Now I agree with you that a unique one-size-fits-all Node interface is
 > definitely not the most elegant solution to the problem.
 > Yet, given Java inheritance model, I think we need a single
 > super-interface all JDOM nodes can be casted to.
 > I also agree that the intersection of the features available from every
 > XML node is empty.
 >
 > So I came up with the following proposal:
 >  - an org.jdom.Node interface that defines a single method int
 > getNodeType() (plus methods such as isLeaf() / isBranch() if you do not
 > like the idea of relying on a bit mask in the node type).
 >  - an org.jdom.LeafNode interface that extends Node and includes the
 > methods available from all existing JDOM leaf nodes (i.e. detach(),
 > getDocument() and get/setParent()) and will be implemented by Element,
 > Attribute, CDATA, Text, Comment, PI and EntityRef.
 >  - an org.jdom.BranchNode interface that extends Node and includes the
 > methods common to Element and Document (i.e. add/get/setContent) and
 > will be implemented by Element and Document.
 >
 > This is actually quite close to Amy's proposal except that there is no
 > root node per se and that the intermediate node is replaced by the sum
 > of branch and leaf.
 >
 > Compared to the previous proposal, only one method is added to every
 > class (getNodeType) and the impact on existing code is limited to having
 > the setter methods (detach, setParent, addContent and setContent)
 > returning a LeafNode or BranchNode object rather than the exact node class.
 >
 > I added the LeafNode and BranchNode interfaces to address your concern
 > about defining interfaces that indeed allow to really make use of
 > polymorphism
 >
 > The values returned by getNodeType() can be built on the constants
 > defined by ContentFilter by setting more bits (LEAF, BRANCH). Using a
 > bit mask also make getNodeType extensible to support advertising new
 > interfaces/features in the future (e.g. a TextContentNode interface that
 > would group in a single interface methods for manipulating the content
 > of CDATA, Text, Comment and Attribute or a NamedNode to group all the
 > name and namespace related-methods in Element and Attribute, etc.)
 >
 > It's also probably a good way to clean up the interface of various JDOM
 > classes (by removing multiple setter methods: add/removeContent(A),
 > add/removeContent(B)...) and of XMLOutputter.

Opinions?

> 2. What is the value of a node?

Opposite to XPath, JDOM does not define what the value of a node is. But is 
this really a problem? XPath does not define a general rule, it simply defines 
what the text value is for each type of node.
We could do the same thing with JDOM (i.e. add a public String 
getValue()/getText() method to each node or to the Node interface) but we 
would still hav e to define what thereturned value is on a per-node basis.

But I'm not sure this would really be useful except for implementing XPath 
engines.

> 5. What's more important? Performance or Correctness?

That's a question no one can answer because it simply depends on the context. 
Even within one application, I need to ensure correctness when interfacing 
with other application while I often want performance while exchanging 
documents between components inside the application (correctness is then taken 
care of by unit tests).

So I'd say: Let's make sure JDOM first ensure the correctness of documents 
with reasonable performances but with validity checks that can be disabled.

Laurent