[From nobody Fri Aug  6 17:07:31 2004
>From - Sat Mar 30 10: 09:43 2002
X-Mozilla-Status2: 00000000
Message-ID: <3CA5FF66.5010405@sosnoski.com>
Date: Sat, 30 Mar 2002 10:09:42 -0800
From: Dennis Sosnoski <dms@sosnoski.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020205
X-Accept-Language: en-us
MIME-Version: 1.0
To: Elliotte Rusty Harold <elharo@metalab.unc.edu>
Subject: Re: [jdom-interest] Re: SAXBuilder enhancement request /2
References: <200203300937.CAA25580@dorothy.denveronline.net>
	<000701c1d7d2$7e10d1a0$0181a8c0@corp.uievolution.com>
	<3CA5961A.7050002@sosnoski.com>
	<p04330100b8cb5b9d63f9@[192.168.254.4]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

You're right, there's no reason to support this in the API. The filter 
Joe pointed to would do a pretty good job of handling the other issue, 
inter-element whitespace. The handling could also be built into 
SAXHandler - Brad pointed out that this already consolidates character 
data, so it'd just need to look for a non-whitespace character before 
processing the data if it's between elements.

  - Dennis

Elliotte Rusty Harold wrote:

> At 2:40 AM -0800 3/30/02, Dennis Sosnoski wrote:
>
>> From a quick look at the code this appears to remove character data 
>> consisting only of whitespace separating elements - it doesn't strip 
>> leading and trailing whitespace from the character data content of an 
>> element. It might be good to change the class description to make 
>> this clear. :-)
>>
>
> White space trimming from elements that contain non-white space data 
> seems even more dangerous to me than removing white-space only nodes. 
> Plus there's less of a use-case for it. It's not like it's all that 
> hard to call String.trim(). I propose that JDOM *not* include any 
> trimming functionality.



]