[jdom-interest] CDATA content is not preserved

[David Wall]

It's not much help, but we ran into problems preserving such newline issues.
If the newlines are needed (if you write CR+LF then you get back CR+LF) to
be kept intact, we had to base64 encode our strings.  It was the only way to
ensure all whitespace was properly preserved (we did digital signature
computations on the values, so the CDATA failed because just one CR+LF to LF
translation and the computation would fail).

David

----- Original Message ----- 
From: "Jason Hunter" <jhunter at xquery.com>
To: "Andreas Schaefer" <aschaefer at SeeBeyond.com>
Cc: <jdom-interest at jdom.org>
Sent: Wednesday, November 24, 2004 4:39 PM
Subject: Re: [jdom-interest] CDATA content is not preserved


> From the XML 1.0 spec:
>
> --
> 2.11 End-of-Line Handling
>
> To simplify the tasks of applications, the XML processor MUST behave as
> if it normalized all line breaks in external parsed entities (including
> the document entity) on input, before parsing, by translating both the
> two-character sequence #xD #xA and any #xD that is not followed by #xA
> to a single #xA character.
> --
>
> Now, we did decide to have XMLOutputter write &#xD; to preserve any
> carriage returns set via setText().  That code's in the
> escapeElementEntities() method.  But of course you can't write &#xD; in
> a CDATA section because it would be treated literally.
>
> I'm not sure there's a way to preserve \r\n in a CDATA section in XML.
>
> -jh-