I have done a good amount of experimentation with XSLT and the XMLTransform() method in ColdFusion; but, up until now, that's all pretty much been with strict XML documents. Over the weekend, I was thinking of re-architecting some parts of my blog and I thought XSLT might just be the best approach. But then it occurred to me that I didn't know if XSLT would play nicely with XHTML-style data. To be honest, I am not even sure if XHTML validates as XML. For the most part, the parallel nature of the two types of document are obvious; the one uncertainty for me is the mixture of text nodes and elements within a single parent.
To see how XSLT and XHTML work together, I set up a simple demo that creates a copy of a chunk of XHTML data by copying each node within it separately:
- <!--- Define XHTML style data. --->
- <cfsavecontent variable="strData">
- <p class="content">
- This is some text with some other formatted text
- <strong>contained within in</strong>. While this is
- valid XHTML, I am wondering how it will hold up
- when put through <em>XSLT</em> node copying.
- <img src="about:blank" /> Embedded image.
- <!--- Define the XSLT. --->
- <cfsavecontent variable="strXSLT">
- <!--- Document type declaration. --->
- <?xml version="1.0" encoding="ISO-8859-1"?>
- <!--- Match all generic nodes. --->
- <xsl:template match="*">
- <!--- Copy this node (non-deep copy). --->
- Make sure that all attributes are copied
- over for the current node.
- <xsl:copy-of select="@*" />
- Apply templates to all of it's child nodes
- (so that they can be copied).
- <xsl:apply-templates />
- Transfor the XHTML. Let's see if this creates an accurate
- copy of the XHTML.
- Trim( strData ),
- Trim( strXSLT )
As you can see, my XSLT is simply copying each node and then recursively calling Copy on each of its child nodes. When we run this code, we get the following output:
<?xml version="1.0" encoding="UTF-8"?> <p class="content"> This is some text with some other formatted text <strong>contained within in</strong>. While this is valid XHTML, I am wondering how it will hold up when put through <em>XSLT</em> node copying. <img src="about:blank"/> Embedded image. </p>
With the exception of the added XML DocType, I am happy to see that ColdFusion's XMLTransform() and my XSLT work quite well with XHTML style data. This verifies that XHTML does indeed validate as XML. Let's see if I can start putting this new found compatibility insight into use.
One thing to keep in mind is that CF8 still ships with the old Xalan processor from Apache. Unfortunately, that parser only supports xslt 1.0 and hasn't had any active development in years. What Adobe really needs to do is upgrade that library to the Saxon-B parser so that it supports XSLT 2.0, XQuery 1.0, and XPath 2.0.
There is a way to swap out the parser for the updated one, but then you have to remember to do it each time you update CF.
This is a good point. However, for most of what I will am thinking about doing, this should be good enough for now. I'll have some more blog posts on the related topics to come.
"To be honest, I am not even sure if XHTML validates as XML" - XHTML was developed to represent HTML as valid XML - http://www.w3.org/TR/xhtml1/#xhtml
Awesome. Good to know. And, since I use XStandard as my blog editor, I can rest assured that all of my blog content is actually XHTML / XML compliant. Man, I love XStandard.
Agree 100% - XStandard is the way to go. It is built into my CMS:
It would be great if they developed an ActionScript version for Flex/Air.
Word up! XStandard is such an awesome editor! I hate when I have to use anything else.
BTW - on topic of XS editor - I noticed in your XS posts you were concerned your web services would not work with v2 and was pleasantly surprised when they did.
The changes to the web services were minor and are listed in the XS OEM docs change log. Mainly added ability to order items returned in response and syntax for max upload size parameters.
The main change was the license file/format.
Yeah, that was pretty exciting :)
Too bad XStandard is NOT written in JS, but a browser plug-in.
Sometimes ultimate power comes with minor compromises :)
Thanks! Your comment spared me a lot of head-banging when I was trying to get some "xsl:character-map" stuff to work in CF 8.
Anyone know what parser CF 9 uses? (yes, I know I could install the beta and find out...)
I'm not sure what the parse is these days. I assume it is the same one - I haven't seen any XML-based updates.
@Mike: Could you explain me the procedure to upgrade the parser to saxon-b for use of xslt 2.0
thx a lot
@Mike probably replaced his JAR file for the XML parsing engine (Xalan.. or is that Xerces)? I'll let him answer the question, but I figured I would give my best guess.
Ben, when I try this approach with a <JOBDESCRIPTION> node that contains CDATA, it strips out the <![CDATA...]]> tag and escapes all of the html characters. When I test it by simply adding the CDATA tag, this is what gets returned. I've been working on this for days now trying everything I can think of and I'm starting to look like I don't know what I'm doing to the bosses here. I'd appreciate any help you can give me. Ray
Oops, it removed all of the formatting for my post, guess I should put it in a code tag, huh? Ok here's the output again...I hope...lol.
- <?xml version="1.0" encoding="UTF-8"?> <JOBDESCRIPTION><p class="content">This is some text with some other formatted text <strong>contained within in</strong>. While this is valid XHTML, I am wondering how it will hold up when put through <em>XSLT</em> node copying.<img src="about:blank" /> Embedded image.</p></JOBDESCRIPTION>
There's no need to post the same question on different blog posts on my site - I get *all* the comments that come through here.
On an unrelated note, can you tell me what happened when the post stripped out your formatting? I just updated my comment code this morning, so I want to make sure that I didn't screw something up.
If you posted markup in the comment, it should have just escaped it (except for Strong and Em tags which it honors). It looks like everything got stripped out, though.