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

RE: [xsl] CDATA Handling

---

---

It's six of one and a half dozen of the other, really, but if you're switching
to processing-instructions, why not use something like:

<x>See following image: <?image base64="R0lGODlhDQANAMQ0IAOw==" ?></x>

That way, the image data wrapper remains an easily-searched-for text pattern,
as well as a single atomic unit in the XML infoset.

~ Scott

-----Original Message-----
From: Evan Lenz [mailto:evan@xxxxxxxxxxxx]
Sent: Tuesday, January 06, 2009 3:47 PM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [xsl] CDATA Handling

That's much better. Wish I'd thought of it.

"A bit nervous" and "not too bad" feels much better than "yuck, this is
a horrible hack". So, short of changing the DTD...what Michael said. :-)

JSR, it would look something like this (using
<xsl:processing-instruction/> to generate the PIs):

<x>See following image: <?start-image?>abcde<?end-image?></x>

Evan

Michael Kay wrote:
>> I'll probably regret this suggestion. No one has mentioned an
>> alternative possibility (still bad architecturally, just not
>> quite as bad as using CDATA delimiters): use non-XML "markup"
>> (text) to delimit the images.
>>
>> <x>See following image: TARTIMAGE##abcde##ENDIMAGE##</x>
>>
>>
>
> Why use non-XML markup? Processing instructions do the same job better.
>
> I always feel a bit nervous about using processing instructions when I want
> to add some markup without changing the DTD. But it's a practical technique
> that works (much better than CDATA sections). I don't feel too bad about it
> if the PI really is being used as an "instruction" (to a stylesheet) to do
> some "processing". And there are cases where (for better or for worse)
> getting the DTD changed really isn't an option.
>
> Michael Kay
> http://www.saxonica.com/

---