[jdom-interest] XMLOutputter

Jason Hunter jhunter at acm.org
Mon Jul 31 20:02:10 PDT 2000

>  So it (XMLOutputter) really needs different "defaults" based on 
> the use-case.  From scratch docs needs the older version with 
> indents and newlines, existing docs need no formatting.

<nonproductive class="rant">
Whitespace, namespaces, and handling children all suck.  Simon warned
me.  He was right.

The idea that we have different defaults depending on how the document
got created leads us into a hornet's nest.  Imagine I have a doc and
it's nicely formatted.  I read it into JDOM.  All that whitespace is
preserved faithfully, even though it's 99.9% formatting.  Then I add a
couple elements here and there from scratch (which have no whitespace
probably) and from other docs (which because of their depth in the other
document may have more or less surrounding whitespace).  

What do I end up with?  

If we preserve whitespace faithfully, then we have one ugly bastard of a
file with indents of different levels all over the place.  If we ignore
whitespace, then we might break that one element in the file whose
content needs whitespace preserved.

<maybeproductive class="dreaming">
What I may write for myself is JasonsFastConfigFileBuilder which builds
a document containing only elements and text content.  It saves memory
and time by ignoring comments, PIs, non-standard entities, whitespace,
and all the rest.  It will create a special Element subclass that
doesn't have all the StringBuffer and instanceof slow-down junk needed
to deal with whitespace.  Elements just have children, text, and
attributes, and return them directly.  I wonder how much faster I could
get the config file reading using that setup instead of a fully XML
compliant builder with a fully XML compliant Element?  Ooh, and imagine
if I used a parser built just for this!  It would be small in memory,
small in code, and run super fast.  Sure it wouldn't solve the world's
problems, but it would solve many people's problems far better than the
existing solutions.  The closer JDOM gets to solving everyone's problems
the worse it's getting at solving these simple cases.


More information about the jdom-interest mailing list