<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: [doom-interest] The JDOM Model, Chapter 15 of Processing XML with Java</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>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?"</FONT></P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2> </FONT>
<BR><FONT SIZE=2>> 1. What is a node?</FONT>
</P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>public interface Node{</FONT>
<BR> <FONT SIZE=2>public Node [] children = get Children(); // * more later....</FONT>
<BR> <FONT SIZE=2>public Node parent = get Parent();</FONT>
<BR><FONT SIZE=2>}</FONT>
</P>
<P><FONT SIZE=2>> 2. What is the value of a node?</FONT>
</P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>> 3. Why does JDOM call only elements children when every other XML </FONT>
<BR><FONT SIZE=2>> specification uses the word "children" to refer to all kinds of nodes?</FONT>
</P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>Warts and all, JDOM is still the prettiest girl at the dance. A new dress and a pedicure, and she'd be a knockout.</FONT>
</P>
<P><FONT SIZE=2>--</FONT>
<BR><FONT SIZE=2>Jerome O'Neil</FONT>
<BR><FONT SIZE=2>Sr Software Engineer</FONT>
<BR><FONT SIZE=2>The Cobalt Group</FONT>
<BR><FONT SIZE=2>206.219.8008</FONT>
</P>
</BODY>
</HTML>