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

[Alex Rosen]

> 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