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

[O'neil, Jerome]

I haven't read your chapter, but I do have some comments on your commentary.
For the most part, I agree completely.  The big holes in the JDOM API stem
from the "specification by implementation" process in which it was born.
Lack of a specification will prohibit answering the one question that a
specification always answers: "When are you done?"

Some of the original "Java vision" is ultimately at odds with a clear API.
In particular, the "no interfaces" idea.  While it may sound nice on the
surface by keeping things "simple" in that all we have to deal with are
concrete classes, not having interfaces *doesn't* in fact keep things
simple.  For an API representing a hierarchical data structure, it makes
things more complex.  Lets look at your first three questions in that
context.
 
> 1. What is a node?

I don't know.  I do know it has one parent, and zero to N children, though.
So how about an interface to describe it.  Then all the concrete classes we
like so much can implement it as best fits their specific tasks.

public interface Node{
	public Node [] children = get Children(); // * more later....
	public Node parent = get Parent();
}

> 2. What is the value of a node?

Nodes have values?  Is that the same as it's children, or perhaps just a
String value? Perhaps we need to extend Node to create Value Node and define
a "getValue()" method.  Perhaps we should discuss, and then specify this
behavior.  Then we should implement it, according to specification.

> 3. Why does JDOM call only elements children when every other XML 
> specification uses the word "children" to refer to all kinds of nodes?

Because JDOM has no specification.  Because it does not prefer interfaces to
define type, it can not enjoy the benefits of same, one of which is
polymorphic behavior.

This is one of the two major complaints I have about JDOM.   Lack of common
interfaces.  I think fixing it requires two things.  A clear specification
of what those interfaces should be, and a major refactoring of the code base
to implement the specification.

The second major complaint I have can be related, but is ultimately
orthogonal to the interface problem.  It's a stylistic issue that I call
"Abuse of Collections."  I've always believed (and continue to do so) that
no publicly defined method should return a collection as a result if the
members of the collection all share a common data type.  It follows that if
they all share the same data type, then you might as well return an array of
them instead, and save your caller a cast.

In JDOM, all nodes do not, in fact, share a common data type.  This makes
the collections returned a necessity.  However, it requires that the caller
do a type check, and then a cast, which is clumsy.

Warts and all, JDOM is still the prettiest girl at the dance.  A new dress
and a pedicure, and she'd be a knockout.

--
Jerome O'Neil
Sr Software Engineer
The Cobalt Group
206.219.8008
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20020506/008c091a/attachment.htm