It is parser dependent. You CAN get a difference in behavior (such as with xerces when it validates against a schema that says an element has NO whitespace, so it reports no whitespace). This is something to be aware of. But sometimes (like now for me) you just HAVE to have it :)
I added a comment to the new RELEASE-NOTES.txt, so maybe I'll update that to say something about it. I can also update the javadoc... Scott > -----Original Message----- > From: robert burrell donkin [mailto:[EMAIL PROTECTED]] > Sent: Sunday, January 13, 2002 12:08 PM > To: Jakarta Commons Developers List > Subject: Re: cvs commit: > jakarta-commons/digester/src/java/org/apache/commons/digester > Digester.java > > > a bit interesting, this one. i think that processing of whitespace is > parser dependent. so unless digester trims you can get a > difference in > behaviour when you changes parsers. (at least, i've always > assumed that > this was the reason why this bit of code was written in that way.) > > i do agree with the change, though. if a user wants to use a > parser that > preserves whitespace then we should allow them to process > that whitespace > :) > > i might check my facts and see if i can maybe put something in the > documentation. > > - robert > > On Saturday, January 12, 2002, at 10:32 PM, [EMAIL PROTECTED] wrote: > > > sanders 02/01/12 14:32:37 > > > > Modified: > digester/src/java/org/apache/commons/digester Digester.java > > Log: > > Need to NOT trim the text in the call to Rule.body(). Space can > > sometimes > > be significant. All rules in Digester trim() anyway. > This will be a > > red > > flag for Rule implementors. > > > -- > To unsubscribe, e-mail: > <mailto:commons-dev-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
