[jdom-interest] Re: First impressions and some suggestions

[Jason Hunter]

> This method could reasonably be called getROT13Content(). However, to 
> call it getContent() just because you had a lot of ROT13 content 
> mixed in with a little or even no non-ROT13 content would be wrong. 

Right, because a programmer would reasonably expect getContent() to
return non-ROT13 content.  However, with JDOM a programmer would
reasonably expect getContent() to return content with trimmed
whitespace.  Remember, Elliotte, you wrote a book called "The XML
Bible".  Your expectations may be a little skewed.  I was sitting there
at JavaOne when the XML Parser presenter said, "What's confusing here is
that you get this whitespace you don't expect."  That's very telling!  I
say give the programmer -- the one who didn't write a book on XML and
just wants to get their program working -- what they expect and most
often need.  Allow the guru to do their job as well.

> But names do have meanings, and we shouldn't arbitrarily change them.
> The meaning of the word "content" in JDOM should be the same as in
> the XML 1.0 spec and all other related specs. Unfortunately, not
> enough attention has been paid to this issue in the past and there
> are indeed terminology conflicts between different specs as well as
> much third party documentation. Some of this confusion I've
> contributed to myself, I'm sorry to say. However, none of this
> resolves us of our responsibility to do the best, most accurate job
> we can despite living in an imperfect world.

I could almost be convinved if it was only getContent() we were talking
about, but I simply have tremendous resistance to having
getMixedContent() on this:

<foo>
  <!-- a demo -->
  <bar />
</foo>

return

String "\n  "
Comment
String "\n  "
Element bar
String "\n"

It was this behavior that first made me say "What the hell?" when I used
DOM a year ago.  Maybe such behavior most closely matches XML spec
terminology, but JDOM isn't a tool for teaching XML.  JDOM is a tool for
getting a job done, and the target demographic (someone who hasn't read
the XML spec and really doesn't care to) will prefer the expected
behavior.  And from my previous email, I think I've made the point that
while you believe the API has methods you'd like to rename, we still
provide the complete functionality required in this area required by the
XML spec.

-jh-