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

Re: [xsl] enclose output of transform in CDATA section


Subject: Re: [xsl] enclose output of transform in CDATA section
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Fri, 15 Aug 2003 13:48:56 -0400

Hi Eliot,

I found your remarks and suggestions vis-a-vis the inclusion of serialized XML as textual content to be very interesting and provocative. It's got me thinking of more than one application of the idea (I particularly like the use of the NOTATION, naturally -- satisfyingly neat and old-fashioned at once), so much so that I can finally see its attraction.

On the other hand, while you've convinced me that it isn't *always* a bad idea to include markup inline that is not intended to be parsed directly by the receiving application (leaving aside trivial examples like inlining XML in papers about XML), I still have to confess that it's always appeared to be a bad idea in the cases where I've seen it.

This is largely because in such cases, due attention has not been given to the architectural issues that Mike raises. You (speaking here of W. Eliot Kimber, Level 15 XML Master) are certainly not going to apply this technique absent some regimen for managing such texts, along with the expectations that may travel with such texts. That is, you are going to make due provision for how this material is being created, how it is validated, and how it is managed at the receiving end. Accordingly, I would trust you not to dump ill-formed HTML in line, and then expect a receiving XML application to be able to do something with it, as if the simple act of disguising the markup as text had tamed it into submission.

Yet while you wouldn't be guilty of playing such a game of Let's Pretend, I can't say that about others. In particular, it's a problem on this list since often the root of the problem is that a new XSLT developer has been charged with making sense of cruft that can't even be parsed, while someone upstream has wrongly represented that there is no cruft there. We are faced with the ambiguous and delicate task of (a) discerning how likely there is to be cruft in this particular situation (what provisions for managing the well-formedness and validity of the inlined XML "notation" have been made in this case), and (b) educating the developer in the ins-and-outs of this problem, even while she or he is often climbing, for the very first time, the learning curve about parsing, serialized instances and their sometimes-problematic relation (particularly in the case of HTML) to the node tree that XSLT requires for its processing.

Determining when this is a reasonable thing to do, and when not, is made even more complex since one of the requirements it is often supposed to address, namely including one kind of markup inside another, can often be handled better through other means (for example by handling validation differently). (Whether namespaces, which were *supposed* to help with this problem, are actually any good for this, I will leave aside as flame bait. :-)

All in all, a very tough problem in the general case. Maybe an Extreme paper.

Cheers,
Wendell

At 10:03 AM 8/14/2003, you wrote:
I completely disagree with Mike Kay on this issue: there is nothing in the XML specification that in any way suggests that it is "inappropriate" to include a syntactic XML document in a CDATA section and I can think of several cases when it would be useful to do so....



====================================================================== 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 ======================================================================


XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list




Current Thread
Keywords