Re: [xml-dev] CDATA headache

[Mukul Gandhi <gandhi.mukul@gmail.com>]

Others have explained, the semantics and limitations of XSLT,
regarding the CDATA elements.

If you must use XSLT, you need to use the solutions as others have
explained (you can look at the latest solution, proposed by David).

I think, DOM can model CDATA nodes, in the XML tree. Perhaps you can
explore DOM, if that might serve your need. Perhaps you can explore a
DOM to DOM transformation using Java APIs. You can later serialize the
output DOM, to lexical XML.

On Wed, Sep 9, 2009 at 4:19 PM, michael odling-smee
<mike.odlingsmee@gmail.com> wrote:
> All,
>
> Firstly apologies if I am posting this to the wrong forum. I am currently
> having an issue convincing my customer that our processing engine is working
> according to XML specifications - the issue is to do with CDATA sections.
>
> In the input document there are various elements that contain CDATA
> sections. The nature of our processing pipeline is to strip off some wrapper
> XML structures (via XSLT) passing on the XML payload where these CDATA
> sections reside. Now the issue is that in the output document the CDATA
> content has been replaced with their equivalent characters individual
> escaped i.e.
>
> <value><![CDATA[<sender>John Smith</sender>]]></value>
>
> becomes
>
> <value>&lt;sender&gt;John Smith&lt;/sender&gt;</value>
>
> Now I am well aware that these are entirely equivalent from an XML
> standpoint - however the customer point of view is if they are equivalent
> why has the parser altered the way the characters are escaped? On this front
> it is unlikely that links to sites such as
> http://www.dpawson.co.uk/xsl/sect2/cdata.html#d3164e447 will be enough to
> convince them that our processor is behaving correctly - they need a formal
> specification. I have searched the XML specification (to no avail) and was
> wondering whether anyone could point me to the relevant place which
> specifies that this is expected behaviour of the parser/xslt processor.
>
> Kind regards,
>
> Michael



-- 
Regards,
Mukul Gandhi