[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

RE: [xsl] Adding CDATA to the transformed XML

Subject: RE: [xsl] Adding CDATA to the transformed XML
From: "Bhaskar, Rajan" <RBhaskar@xxxxxxx>
Date: Thu, 13 Jan 2005 09:52:56 -0500

Sure. I'm checking with the folks who developed the sub-system and
hopefully resolve it instead of passing it with CDATA


-----Original Message-----
From: Wendell Piez [mailto:wapiez@xxxxxxxxxxxxxxxx]
Sent: Wednesday, January 12, 2005 6:40 PM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE: [xsl] Adding CDATA to the transformed XML

The OP hasn't said exactly, but it sounds to me like the other subsystem
some sort of interface that lets users input whatever they like into the

Since they can input anything from their keyboard, they occasionally
stuff like "&" which of course doesn't parse.

In any case, what Mike said is still correct. The XSLT process that
transforms this XML doesn't need to force a CDATA marked section
because the serializer will do any necessary escaping. That is, if the
problem is in the other subsystem, forcing CDATA in this one will
nothing. The real solution is to fix the other subsystem so it converts
disallowed characters into their allowed representations, or does a
wrapping of its own as a poor-man's version of the same.

So I'm guessing the the problem is not in a parser, but rather in a tool
UI or something, maybe just a text editor) that allows users to input
malformed data and doesn't correct it for them before passing it over. A

compliant parser is part of the fix; but we don't know that that the
offending subsystem uses a parser at all.


At 11:21 AM 1/12/2005, it was written:

> > No the other Sub system does not use XSLT
>The point they are trying to make is that provided the other 'Sub
>system' is a compiant XML parser, then anything produced by a transform
>using the xml output method should parse ok.
>If the parsing is failing at the other end, then it's a problem with
>parser and a fix should be applied there rather than bodging your
>to a work around the non-comformity.
>What characters made the parsing at the other end fail?  It could be
>that you are mis-using disable-output-escaping?

Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
   Mulberry Technologies: A Consultancy Specializing in SGML and XML

Current Thread