Re: ANN: JDOM

Arnaud Le Hors wrote:
> 
> Hi all,

And an awful lot of "all" there are!  I'm replying to everyone since 
I think we need to hear from both viewpoints here.  PLEASE IF YOU WANT
TO REPLY, join and post to jdom-interest (see http://jdom.org for
sign-up).

> I'll be the first one to say that the DOM is far from being the
> cleanest and leanest API one could dream of but, unlike JDOM, at 
> least it truthfully represents XML.

The goal of JDOM is to solve 80% (or more) of a Java programmer's XML
problems with 20% (or less) of the traditional effort.  We also need to
be lightweight and fast.  This means that some end cases will not be
supported, because to support them would overly complicate learning the
API, overly complicate using the API, require too much memory overhead,
and/or require too much CPU work.

> JDOM appears to fail to even simply represent the XML document tree as
> it should. Processing instructions, for instance, aren't found in the
> tree but instead are stored at the document level.

Yes, this was a conscious decision.  In our analysis, we believe that
PIs are (by far) most commonly used by Java programmers without regard
to placement in the Document.  Cocoon is a good example.  By our
attaching PIs to the Document itself they can easily be retrieved
together, retrieved by name, and manipulated as a set.  Order of
appearance is always respected.  

We could place them in the tree like we place Comment objects.  But do
people really think that's part of the 80% and that losing the
simplicity and efficiency of retrieval (you'd have to walk the tree to
get them) doesn't extend us beyond the 20%?  That's a serious 
question.  Post answers to jdom-interest.

> JDOM confuses entity references and entities. While entity refs are
> represented by an Entity object, entities are simply absent.

Entities are an area of active design.  We haven't talked much about
them because they aren't finished.  Please join the jdom lists and make
suggestions.

> The way namespaces are handled show a clear misunderstanding of the
> basics of XML namespaces and, unless a serious redesign is undertaken,
> it will only work for simple cases.

It doesn't represent a clear misunderstanding.  It represents an
intentional simplification.  Implementing scoped namespaces
*efficiently* is quite a challenge.  The obvious approach is to store
all the namespace information inside every Element, but that causes
tremendous memory bloat and makes it a lot harder to move elements
between documents.  We're investigating good designs.  If you have
ideas, pipe up.

> So, if the DOM is "ridiculously complex", JDOM appears to be
> ridiculously simple... Sorry, I couldn't resist. ;-)

Hey, Java can't do everything C can do either.  :-)

-jh-

P.S.  Remember, follow-ups to jdom-interest.  Let's not annoy everybody.