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

[Jason Hunter]

Alex Rosen wrote:
> 
> > As an XML developer, JDOM frequently surprises me. That's not good.
> > It makes the simple things simpler than DOM, but it makes the complex
> > things  harder. When faced with a complex problem that requires me to
> > consider all the nasty bits of XML and not just shallow documents
> > with a few elements and attributes, then I turn to DOM, not JDOM.
> > DOM's a mess; but it's mess is all on the Java side of the house. Its
> > XML model, while imperfect, is very clear, very well-defined, and
> > very consistent. JDOM's isn't. JDOM's mess is all on the XML side of
> > the house.
> 
> Wow, this is a very insightful post. I agree completely: DOM is an XML
> weenie's view of an XML API, while JDOM is a Java developer's view of how
> XML would look without some of its ugly blemishes. DOM's job was just to
> model XML directly, warts and all. JDOM tried to make it simpler, more
> elegant, and more pleasurable to use. The mess is that there are some things
> that simplify your life 95% of the time, but limit you 5% of the time. JDOM
> was made for the "I just want to read some XML dammit, why does it have to
> be so hard?" case. The recent discussion about the DOCTYPE location is an
> example. Most of the time you don't care where exactly the DOCTYPE is
> located, and thinking of it as a property of the Document and not mixed in
> with the content is much simpler. But 5% of the time you do care, and we
> lose this information. The question is, is it worth it to make JDOM easier
> in the 95% case if that eliminates its use for 5% of your projects? Should
> JDOM become just a Java developer's view of XML, warts and all? Is that
> enough of an improvement over DOM to make JDOM worthwhile?
> 
> Alex

That's an excellent description of the DOM and JDOM points of view!

-jh-