[jdom-interest] Stirring up Trouble

[Jason Hunter]

> >It does what the docs say it does.  Which for JDOM is trim the
> >whitespace, because getMixedContent() has to follow suit and I'll be
> >damned if getMixedContent() is going to return all the intermediary
> >whitespace elements in its simplified form.
> >
> 
> I really think JDOM is the wrong place to be making this judgement.
> Your argument is really with what XML parsers should be doing.

I disagree.  The reason I put effort into creating JDOM was to have an
API for reading and manipulating XML that was convenient.  That's my
number one goal.  That convenience has tended to mean better
performance, then great!  That convenience has tended to mean
lighterweight, then great!  That convenience can be done while being XML
1.0 spec compliant, then fabulous!  That's where I'm coming from here.

Now, I would need to be convinced that leaving the whitespace around
content by default is more convenient.  Take the email from Robin Meade
that came through just a few minutes ago...

> An example of where getXXX methods would be useful on 
> elements is the Servlet 2.2 specification's web.xml 
> file. It uses elements like this
> 
>       <param-name> name1 </param-name>
>       <param-value> value2 </param-value>

Notice his spaces around the name and value.  It's a natural way for
someone to enter the name and value.  Since XML for config files is a
very common use of XML, I find this a compelling example where
convenience dictates not leaving the whitespace.

> I was doing some work with XPointers today and noticed
> that white space including pure white space nodes are significant in
> XPointer as currently written. So that's just one more spec not
> handling white space properly will prevent JDOM from implementing.

NOT TRUE!

Elliotte, I've told you this before in public and in private email.  We
can fully support XPointers.  We don't remove the whitespace from the
document (not sure the current implementation does the right thing
there, but if not that's a bug).  That information is available (just
call the method version that takes a boolean) so XPointer can of course
be implemented.  The only thing being decided is whether the
getContent() convenience method calls getContent(false) or
getContent(true).  As someone who wants the convenience method to be
convenient, I'm in favor of "false" based on my own coding experience,
and would need war stories from people who find it more convenient to go
the other way to be convinced.

-jh-