[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Hi Scott,
Your approach would be slightly easier to process and it fits nicely, hierarchically. I also think you're right it's probably neither here nor there. But I'd probably still go with the start/end markers for a few (rather weak) reasons:
1. The image itself isn't really an "instruction" for "processing," but data itself.
2. I'd have a vague fear of running afoul of software limitations (however erroneous) that restrict PI sizes due to the assumption that nobody would ever do such a thing (because they don't usually).
3. If the DTD gets unlocked later on and they switch to using elements, the string-value of <x> wouldn't change.
Conversely, if you're currently relying on <xsl:value-of select="x"/> and you later move the image data from inside a PI to element content, gobbledygook will appear all of a sudden.
They're all dubious reasons, I know. But I thought it polite to write a response. :-)
Evan
Scott Trenda wrote:
Re: [xsl] CDATA Handling
Subject: Re: [xsl] CDATA Handling From: Evan Lenz <evan@xxxxxxxxxxxx> Date: Tue, 06 Jan 2009 16:01:57 -0800 |
Hi Scott,
Your approach would be slightly easier to process and it fits nicely, hierarchically. I also think you're right it's probably neither here nor there. But I'd probably still go with the start/end markers for a few (rather weak) reasons:
1. The image itself isn't really an "instruction" for "processing," but data itself.
2. I'd have a vague fear of running afoul of software limitations (however erroneous) that restrict PI sizes due to the assumption that nobody would ever do such a thing (because they don't usually).
3. If the DTD gets unlocked later on and they switch to using elements, the string-value of <x> wouldn't change.
Conversely, if you're currently relying on <xsl:value-of select="x"/> and you later move the image data from inside a PI to element content, gobbledygook will appear all of a sudden.
They're all dubious reasons, I know. But I thought it polite to write a response. :-)
Evan
Scott Trenda wrote:
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.Why use non-XML markup? Processing instructions do the same job better.
<x>See following image: TARTIMAGE##abcde##ENDIMAGE##</x>
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/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] CDATA Handling, Scott Trenda | Thread | RE: [xsl] CDATA Handling, G. Ken Holman |
RE: [xsl] CDATA Handling, Scott Trenda | Date | RE: [xsl] CDATA Handling, G. Ken Holman |
Month |
Keywords