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

[Elliotte Rusty Harold]

At 10:46 AM -0700 6/11/00, Jason Hunter wrote:

>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.

Yes, I'm willing to allow a utility method that returns the trimmed 
content. I'm not sure it's useful, or worth the complication to the 
API, (then again, I'm not sure it's not either) but I don't think 
it's wrong per se.

> 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.

No, I think it's wrong if a method called getContent() returns 
anything other than the actual content. It wouldn't bother me at all 
if the trimming method had the shorter name getTrim() (Well actually 
it would, but for different reasons)

Suppose, for arguments sake, you found useful and had written a 
method that returned the content of an element after deROT13ing it. 
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. 
Performing other transformations inside getContent() such as 
stripping white space is also wrong.

>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.
>

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.

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo at metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
+----------------------------------+---------------------------------+