[jdom-interest] XML spec compliance/convenience (was Re: First impressions...)

[Simon St.Laurent]

At 10:46 AM 6/11/00 -0700, Jason Hunter wrote:
>> I disagree that this API is fully spec compliant. I think you're
>> telling me that you feel the XML spec is wrong; that white space
>> should be less significant than XML 1.0 actually makes it. 
>
>I don't disagree with the spec at all!  The spec writers realized that
>some applications would require the surrounding whitespace, so they made
>it clear that a parser couldn't ignore the whitespace and had to pass it
>on; in other words, had to make it available to applications that needed
>it.  That's exactly what we're doing!  The spec doesn't say,
>"Surrounding whitespace must be available by a method with a shorter
>signature than the method that returns non-surrounding whitespace." 
>That's our decision.
>
>> not some
>> bowdlerized construct that's sort of like the content but not quite.
>> If you want to provide a utility method so developers don't have to
>> call trim(), then that's the one that should have a different name,
>> something like getTrimmedContent() or getNormalizedContent().
>
>Good, so you're willing to concede that it's OK to have two methods A
>and B where one returns surrounding whitespace and one doesn't.  But,
>somehow, you think it's spec non-compliant if the signature for trimmed
>is longer than that for untrimmed, but compliant if the signature
>lengths are reversed?  That doesn't make sense.  The XML spec doesn't
>have any say over the signatures of A and B.  By your own logic, having
>two methods (one for each behavior) is spec compliant, and whether we
>use a boolean flag or different names to distinguish between the two is
>a language and implementation detail and can't change spec
>compatability.

The two methods approach seems reasonable to me, but I have a few suggestions.

First, all of these need to be flagged as to whether they deliver content
'the way the spec says' or 'the way we find convenient'.  Ideally, I'd like
to see some addition to the javadoc that lists all of the spec-compliant
methods and all of the alternative methods in a way that makes the
distinction clear.

Second, I doubt whether any single whitespace-trimming algorithm will be
appropriate to every situation.  It might be worthwhile to make sure that
this trimming is easily extended/modified.  (I haven't looked at this code
myself yet, so you may already have done it.)

With those two caveats, I think we can probably make everyone happy...

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
http://www.simonstl.com