[jdom-interest] Re: FW: feedback on jdom-1.0-rc1

[Jason Hunter]

Thompson, Bryan B. wrote:

> Hello,
> 
> I appear to be unable to post, through I recently subscribed.  The problem
> may be with my email
> address (thompsonbry at saic.com vs bryan.b.thompson at saic.com or some such).

Yes, because the list address is well known, it receives a lot of spam. 
  The only practical way to deal with it is to restrict posting to 
members.  If you post from more than one account, just subscribe under 
each and mark the extras as "nomail" in the admin interface.  I used to 
moderate through non-member posts, but finding the one good one in 1,000 
spams isn't a job I want anymore.

> I wanted to provide some feedback on jdom 1.0 rc1.  This is my first
> experience with jdom.  This report is based on an integration effort of an
> XPointer Framwork processor [1] [2] to use the jdom package.  The
> integration took approximately one day.
> 
> Outstanding points that I was happy about: 
> 
> - The Attribute.getAttributeType() method correctly reports ID-ness based on
> an internal or external subset for a validating processor and correctly
> reports ID-ness based on an internal subset for a non-validating processor.
> This made my life MUCH easier when integrating jdom into the XPointer
> Framwork.
> 
> Things that were not so easy: 
> 
> - It is difficult to serialize a piece of an XML document as XML.  Right now
> this has to be done in "user code" and the code needs to examine the
> specific type of Object, which may be any of several different root classes.

True.  In SAXOutputter we have outputFragment(Content) but in 
XMLOutputter we never adopted the Content abstraction.  No specific 
reason we didn't.  Hmm, would adding an output(Content) break any 
existing code?

> - It is difficult to compare pieces of an XML document - only referential
> identify comparisons are supported in the API.  While there is no cannonical
> XML (yet!), it would be nice to package up a utility for comparing XML
> fragments.

It's a good idea, and anyone who wants to write such a thing can get it 
added to jdom-contrib.  If there were to become a standard algorithm, we 
would include it in the core.

> Other comments: 
> 
> - JDOM does not expose the parsed internal or external subset.  The internal
> subset is only exposed as a String, while the external subset is not exposed
> at all.  It would be nice to see both the internal and external DTD subsets
> exposed for inspection and modification.

Right, we debated that long ago and in the end decided a string got you 
80% of what you needed (in roundtripping and manual editing) for 20% of 
the work.  If you have real interest in this, I'd welcome you to sketch 
a design and implementation.

> - Attributes are not visited by recursive descent iterators, which might be
> nice. 

I can see that.  It would make some things nice.  I don't think now's a 
good time to change it though.

> - There is no common base class for all objects in the document model.  This
> means that serialization and equality methods have to be written somewhat
> piecemeal.  I'm sure that you've considered a common root class.  I'm
> curious why you choose to reject it for the API.

It's a good idea in general, but gets messy when you try to implement 
it.  There's almost no common functionality across all the object types, 
so you'd have a Node interface that's nothing but a blank marker.  That 
not much of an advantage over Object.  In the end we went with Parent 
and Content since there is some overlap between parent classes and 
child/content classes.  Of course, you heard someone this morning say 
they wish we hadn't.  You can't please everyone here.

-jh-