preserving markup

[David Schwartz]

've got some javascript and HTML I want to enter directly into my xml
document. I've entered the JS and HTML content into a tag that's
defined as text in the schema. When I process my xml, the > and < in
the JS and HTML are output as named entitles &lt; and &gt;. As a
result, this content is interpreted by the browser as page content
rather than code/markup to be processed and rendered.

I've tried using just the non-escaped content as well the following
templates but the named entities always appear in the output.

<xsl:template match="code">
<div style="MARGIN-LEFT: 30px">
<xsl:text disable-output-escaping="yes">&lt;![CDATA[ </
xsl:text>
<xsl:value-of select="."/>
<xsl:text disable-output-escaping="yes">]]&gt;</
xsl:text>
</div>
</xsl:template>

<xsl:template match="code">
<div style="MARGIN-LEFT: 30px">
<xsl:value-of select="." disable-output-escaping="yes"/>
</div>
</xsl:template>

Any help would be appreciated!!

TIA,
David

 

[Joseph J. Kesselman]

Disable-output-escaping should be an absolute last-resort solution;
there is almost always a better way.

If your stylesheet needs to force the content of some elements to be
output as a CDATA section to support broken downstream processing, use
xslutput's cdata-section-elements attribute.

Though personally I consider that a hideous concept. No properly-written
downstream application should care whether you use <![CDATA[]]> or
individually escape characters; semantically those two approaches are
exactly the same. I grant that some older tools are broken in this
regard, but ... yecch.

 

[David Schwartz]

If your stylesheet needs to force the content of some elements to be

output as a CDATA section to support broken downstream processing, use
xslutput's cdata-section-elements attribute.

Thanks for the quick response Joel. Not sure what you mean by 'broken
downstream processing'. I'm outputing HTML (and Javascript), not XML.
cdata-section-elements appears to be appropriate only where
method=xml. Perhaps I'm missing something?

Is this what you had in mind?

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/
Transform">
<xslutput omit-xml-declaration="yes" method="html" cdata-section-
elements="code"/>
<xsl:template match="code">
<div style="MARGIN-LEFT: 30px">
<xsl:value-of select="." />
</div>
</xsl:template>
</xsl:stylesheet>

 

[Peter Flynn]

If your stylesheet needs to force the content of some elements to be

Thanks for the quick response Joel. Not sure what you mean by 'broken
downstream processing'.

Browsers. Most (all?) of them are hopelessly broken when it comes to
handling XML. Fortunately...

I'm outputing HTML (and Javascript), not XML.

....in which case you can get away with it.

///Peter

 

[David Schwartz]

Thanks but you didn't address whether the output statement was what
was intended.

 

[Joseph J. Kesselman]

I'm outputing HTML (and Javascript), not XML.
cdata-section-elements appears to be appropriate only where
method=xml. Perhaps I'm missing something?

Yes, <xslutput cdata-section-elements="code"/> was what I intended.

Some references (including Michael Kay's book, which is one of the best
hardcopy references I've seen for XSLT) do claim that
cdata-section-elements is marked as "not applicable to html output".
However, I've just rechecked and I don't see that restriction in the
XSLT Recommendation itself. All I can say is "try it, and if it doesn't
work ask the processor's authors why not."

But: No program ought to care whether you've used CDATA sections or
individual-character escaping; that distinction is purely a convenience
for humans. Any program which *insists* on one representation or the
other is not processing the documents as intended by their spec. There
are a few special cases where CDATA sections are worth considering --
mostly when the document source is intended to be hand-edited by humans
-- but even there I consider them excessively fragile. So I would also
beat up whoever wrote the code that is foisting this requirement upon you.