Formatting XML CDATA paragraphs via XSLT

You're right - it wasn't very clear. I've attached an example.

There are no HTML tags in the CDATA. It is simply a few paragraphs of text, separated by line breaks (don't know if they're CRLF or whatever) in the XML.

The website the data was stored on could export to HTML and it formatted the text by basically replacing every newline with a br tag. That way although it was rendered in a paragraph, you still got the breaks where I wanted them.

<?xml version="1.0" encoding="UTF-8"?>
<ReleaseNotes>
  <sReleaseTitle><![CDATA[Some Text]]></sReleaseTitle>
  <bug>
    <ixBug>123</ixBug>
    <sCategory><![CDATA[Feature]]></sCategory>
    <sTitle><![CDATA[More Text Here]></sTitle>
    <sReleaseNotes><![CDATA[This is the long text.
 
This is the first paragraph of the long text.
 
This is another one. There is no HTML in here, but when the same release notes are generated as HTML, the output has a paragraph section containg a number of br tags at the relevant points.
 
As you can see, the XML simply has some CDATA which preserves the line breaks.]]>
    </sReleaseNotes>
  </bug>
</ReleaseNotes>

                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:

> don't know if they're CRLF or whatever

don't worry about that: linebreaks are normalized when XML is parsed. That's mandatory and one of the benefits of using a standard. They're all 
 internally.

If you use XSLT 1.0 and not XSLT 2.0 (you can do so by using Saxon for .NET if you wish: www.saxonica.com, the free version), then text processing is a tricky and hard task (I know, you assumed this would be easy, right?). You need to parse it recursively in your XSLT. If you'd use XSLT 2.0 however, a simple tokenizing and a for-each loop would do.

When I first wrote the question, I was using an asp:xml control in an ASP.NET page. This wasn't ideal, though, as it didn't give me any control over the header of the page, so I'm now doing it differently.

I'm using .NET's XslCompiledTransform which combines the xslt file and the xml file into the HTML output. I don't know enough about it to know how to make it do custom things. A quick glance at the docs shows that it implements the XSLT 1.0 syntax, though.

private void LoadXml(string filePath) {
    XPathDocument myXPathDoc = new XPathDocument(filePath);
    XslCompiledTransform myXslTrans = new XslCompiledTransform();
    myXslTrans.Load(Server.MapPath(".\\ReleaseNotes.xslt"));
    StringBuilder sb = new StringBuilder();
    StringWriter sw = new StringWriter(sb);
    myXslTrans.Transform(myXPathDoc, null, sw);
    sw.Close();
    sw.Dispose();
 
    Response.Clear();
    Response.ContentType = "text/xml";
    Response.Write(sb.ToString());
    Response.End();
}

                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:

Yes, you are correct, XslCompiledTransform implements XSLT 1.0 only. However, using XSLT 1.0 with C# has a different advantage: you can use extension functions to help you with this kind of parsing.

We'll (you'll) have to decide how to tackle this beast: either we stick to XSLT 1.0 with ext functions or in pure XSLT 1.0, or we use Saxon .NET and use XSLT 2.0 syntax.

I'd rather just go for the quickest fix for now. If that means writing an extra method in .NET to add br tags, I'd be happy with that.

How do you add an extension function?

You can add an extension function(s) as follows:

1. Create a public class that can be instantiated from your code above 
2. Add any method you like, for instance convertNewlineToBr(string s) 
3. Set debugging to true: new XslCompiledTransform(true) 
4. In the XsltArgumentList, call AddExtensionObject and add your class (new YourClass()) and give it a namespace. This namespace must exist in the stylesheet. 
5. In the XsltSettings, set both to true 
6. In the XSLT file, call your method by its method name, prefixed with the namespace extension 

Thanks for these suggestions. I think this is along the right lines. I still need some more help to actually get something that works, though.

Option 1:

* I don't know where these properties reside that you mention in steps 4 and 5.

Option 2:

* I don't actually have an xsl:stylesheet root element. The xslt file starts with an xml declaration and then an opening html tag. I can play about with it, though. I see the default from Visual Studio so I'll copy that.

* Does it matter what i put in the xmlns:convert value? Does it need to point to the actual class that contains the function?

>  I don't actually have an xsl:stylesheet root element.

I mean the file that you refer to here, in this line:

myXslTrans.Load(Server.MapPath(".\\ReleaseNotes.xslt"));

which must be an XSLT file and must start with xsl:stylesheet or it is not an XSLT stylesheet...

> Does it matter what i put in the xmlns:convert value? Does it need to point to the actual class that contains the function?

that's about option "2", where you use the inline possibility with msxml scripting. You can point it to anything, it is a namespace as any other, but one you define. It does not need to exist (as no namespace needs to exist, it is just a unique name, that's all). It cannot, however, have the same value of one of the other namespaces, and it must be a valid URI (but again: does not or should not exist).

Let's focus on option 2 for now, as that is easier.

// xslt settings:
XsltSettings xsltSettings = new XsltSettings(true, true);
 
// xslt arguments (if you want to do option 1 some day)
XsltArgumentList xsltArgs = new XsltArgumentList();
xsltArgs.AddExtensionObject("http://blabla.com", new YourClassHere());
 
// enabling debugging
XslCompiledTransform xslt = new XslCompiledTransform(true);
 
// use the xslt settings:
xslt.Load("yourxsltfilehere.xslt", xsltSettings, null);
 
// use the xslt arguments with the (option 1!) ext methods
xslt.Transform("input.xml", xsltArgs, File.Open("output.xml", FileMode.Create));

                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:

PS: not to be nitpicking, but isn't this quite beyond "easy" by now (hint: points)? Don't worry, I'll help you all the same ;-)

I was going to up the points actually, but certainly happy to do so.

I realise that my original xslt file was not really well formed at all, but it worked in a weird sort of way.

I'm now getting this error:

Execution of scripts was prohibited. Use the XsltSettings.EnableScript property to enable it.

The only place I see that property is in XsltSettings.Default.EnableScript. Is this something I should set in the actual xslt file?

> Execution of scripts was prohibited. Use the XsltSettings.EnableScript property to enable it.

well, I believe I was quicker then you: see my penultimate comment about XSLT Settings.

But you're getting close!

>  Is this something I should set in the actual xslt file?

no. It is a security thing. The XSLT files are texts and are used in other ways then through C# code as you do. To prevent illegal scripts (which can open up holes or do things on your system) this is disabled by default. Long story short: you should set it through code as explained above.

Sweet! I have success!

I really knew absolutely nothing about XSLT 24 hours ago when I started looking at using it, so it's no surprise I was all over the place there.

It's funny to think that I had to do all that simply to be able to run this line of code:

return s.Replace("\n", "<br />");

Thanks for your help!

Very helpful, and nice quick responses.

Yes, indeed. Things that are easy in one language aren't always so easy in others. As a matter of fact, this string manipulation thing is one of the most criticized "features" of XSLT 1.0 and was greatly addressed in XSLT 2.0, including string replace and regular expressions support, as well as tokenizing etc.

Thanks for upping the points, glad I could help!

-- Abel --

So is .NET likely to support that any time soon, do you reckon?

.NET supports anything written in .NET. It is a component based system. You can use Saxon.NET for XSLT 2.0, which is a port of the Java version of Saxon. It is extremely standard compliant (has scripting extensions though, which is allowed by the standard anyway) and is written by the creator (chief editor) of the standard.

And who knows, Microsoft said they would do it, but so far, they haven't come with anything but promises (and no timeline).

-- Abel --

That's interesting. I would maybe look into Saxon if I was going to be spending more time with XSLT, but I think this is going to be a quick and dirty one-off so I'll just stick with what the Framework has to offer for now.

Thanks again for your help.