Hi Sebastiaan,

A CDATA section can only contain text, so the processor silently ignores your attempt to generate elements inside an element flagged for CDATA output. 

You need to generate text-versions of the elements inside - take a look at this stylesheet - try to run it on any XML input document (even itself) to see the result:

 <?xml version="1.0" encoding="utf-8" ?>
<xsl:stylesheet
        version="1.0"
        xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
        xmlns:mydata="#not-used-at-all"
>
        <xsl:output method="xml" indent="yes" omit-xml-declaration="yes"
                cdata-section-elements="mydata:free description"
        />

        <xsl:template match="/">
                <output>
                        <description>
                                This is the first description element
                        </description>
                        
                        <mydata:free>
                                <p>
                                        This is not being output as a CDATA Section
                                </p>
                        </mydata:free>
                        
                        <mydata:free>
                                &lt;p&gt;
                                        This should actually come out as CDATA
                                &lt;/p&gt;
                        </mydata:free>
                        
                        <mydata:free><![CDATA[
                                <p>
                                        This should actually come out as CDATA being no different from the above
                                </p>
                        ]]></mydata:free>
                </output>
                
        </xsl:template>

</xsl:stylesheet>

Now, I don't know what your newsletterContent template looks like, but let's say I had a chunk of XML I needed to create as text for CDATA output, I'd create a template for it and set the mode attribute to 'text' or similar, and then do like this (include 'code' in the cdata-section-elements attribute):

<code>
        <xsl:apply-templates select="*" mode="text" />
</code>
...

<!-- Template for text-mode output of elements -->
<xsl:template match="*" mode="text">
        <xsl:value-of select="concat('&lt;', name(), '&gt;')" />
                <xsl:apply-templates select="*" mode="text" />
        <xsl:value-of select="concat('&lt;/', name(), '&gt;')" />
</xsl:template>

Thanks for that, I am probably doing it wrong but the newsletterContent template looks a bit like this now:

<xsl:template match="*" mode="text" name="newsletterContent">
 <table>
  <tr>
   <td>Some data</td>
  </tr>
 </table>
</xsl:template>

It also calls a few other templates, do I need to put them into text mode as well?

Ps. I'm still having a really hard time understanding how apply-template works as opposed to simply calling a template which is almost like calling a function.

Ah, well, something happened when I changed it into this:

<xsl:template match="*" mode="text" name="newsletterContent">
<![CDATA[
 <table>
  <tr>
   <td>Some data</td>
  </tr>
 </table>
]]>
</xsl:template>

But, of course, <xsl:value-of select="$bla" /> in there will also be turned into plain text, so that doesn't help either..

So. Back to the hack, you mentioned something about disable-output-escaping... where and how would I use it?

Hi Sebastiaan,

You can always break out of a CDATA Section if you need to (kinda like what you'd do in the good old days with ASP or PHP):

<xsl:template name="newsletterContent" mode="text">
<![CDATA[
<table>
    <tr>
        <td>
]]><xsl:value-of select="$blah" /><![CDATA[
        </td>
    </tr>
</table>
]]>
</xsl:template>

- but I'd only do that if I had like two or three things to output - it's a mess in XSLT just as it is in ASP/PHP...  

Using the match="*" attribute only makes sense if you're otherwise using match templates and apply-templates, which I get the vibe you're not, so you should probably use the approach above (unless you really want to start pulling things apart). It really depends on the complexity of your newsletterContent template. 

/Chriztian

Thanks Criztian, was afraid of that. For now I got another tip to simply solve it: Use a template and only get the description content through an XSLT macro. Then you can enclose the whole description element in a CDATA block. This won't work for everybody, but it's fine for my purposes.

<%@ Master Language="C#" MasterPageFile="/umbraco/masterpages/default.master" AutoEventWireup="true" %>

<asp:Content ContentPlaceHolderID="ContentPlaceHolderDefault" runat="server"><?xml version="1.0" encoding="UTF-8"?>
    <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
      <channel>
        <title>Test</title>
        <link>http://www.domain.com</link>;
        <pubDate>Sat, 17 Jul 2010 14:51:35 GMT</pubDate>
        <generator>umbraco</generator>
        <language>nl</language>
        <description>Test</description>

        <atom:link rel="self" type="application/rss+xml" href="http://www.domain.com" />

        <item>
          <title>Title</title>
          <author>Me</author>
          <link>http://www.domain.com</link>;
          <pubDate>Wed, 07 Apr 2010 17:43:39 GMT</pubDate>
          <guid>http://www.domain.com</guid>;
          <description>
        <![CDATA[
              <umbraco:Macro Alias="MailingRss" runat="server"></umbraco:Macro>
        ]]>
          </description>
        </item>
      </channel>
    </rss>
</asp:Content>

That's actually a neat solution - I often forget to think outside of the box because I develop 95% of my XSLT locally without server-side processing, so I wouldn't have thought of this.

It's great because you can (probably) leave the original XSLT that generates the content untouched.

/Chriztian 

is working on a reply...