[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Daniel:
I agree with Joerg, with the following caveats:
* Keep in mind, as always, that relying on disable-output-escaping ties your process both to an XSLT engine that implements d-o-e, and to a particular processing model (the result tree must be serialized to a character stream for the transform to be complete). If you can live with that, cool.
* You're going to have to watch out for "real" bracket characters in your data ... they too will be converted to < and >. Short of fancy and error-prone heuristics, there is no way around this, since your problem itself violates the first principle of the markup paradigm on which XSLT is based, which might be phrased (with apologies to Kipling fans -- oops, I forget, there are no Kipling fans any more): "Data is data and markup is markup, and never the twain shall meet". (This would be true even if you did it the recursive way.)
* For the same reason, there's no way of assuring that the output you get will be well-formed XML until you already have it and are able to test it.
The same transform could be done as easily, or more so, with Perl or sed. (Indeed, better, since their support of regular expressions gives you at least some hope of working around any real brackets that might turn up.)
At 04:34 PM 4/25/2002, Joerg wrote:
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Re: [xsl] string replacement for HTML tags
Subject: Re: [xsl] string replacement for HTML tags From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx> Date: Thu, 25 Apr 2002 17:28:41 -0400 |
Daniel:
I agree with Joerg, with the following caveats:
* Keep in mind, as always, that relying on disable-output-escaping ties your process both to an XSLT engine that implements d-o-e, and to a particular processing model (the result tree must be serialized to a character stream for the transform to be complete). If you can live with that, cool.
* You're going to have to watch out for "real" bracket characters in your data ... they too will be converted to < and >. Short of fancy and error-prone heuristics, there is no way around this, since your problem itself violates the first principle of the markup paradigm on which XSLT is based, which might be phrased (with apologies to Kipling fans -- oops, I forget, there are no Kipling fans any more): "Data is data and markup is markup, and never the twain shall meet". (This would be true even if you did it the recursive way.)
* For the same reason, there's no way of assuring that the output you get will be well-formed XML until you already have it and are able to test it.
The same transform could be done as easily, or more so, with Perl or sed. (Indeed, better, since their support of regular expressions gives you at least some hope of working around any real brackets that might turn up.)
Cheers, Wendell
At 04:34 PM 4/25/2002, Joerg wrote:
Hello Daniel,
I think this is a legitimate use case for disable-output-escaping.
<xsl:template match="data"> <xsl:value-of disable-output-escaping="yes" select="translate(., '[]', '<>')"/> </xsl:template>
So with translate() you don't need a recursive approach.
====================================================================== 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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] string replacement for HT, Joerg Heinicke | Thread | Re: [xsl] string replacement for HT, David Carlisle |
Re: [xsl] Extending xsltproc?, Steve Ball | Date | Re: [xsl] Fwd: Over/under trimming , Thomas B. Passin |
Month |