XSLT is a method of transforming XML with a set of rules, functions, and selectors. Transformations can be complex or simple, but the benefit of using XSLT is immediately obvious after first use.
Consider the following:
<posts>
<post>
<title>XSLT!</title>
<description>A short post about XSLT</description>
<content date = "01/03/2009">
Lorum ipsum
</content>
</post>
<posts>
The naive approach of displaying this to the user is to manually parse the data with an XML parser of some kind. I’ve done this in previous projects; it works, but it’s generally stuck in code, which means that changes to the output format require recompilation or some other elaborate build and deployment. This is inherently wrong given the process that’s taking place. A transformation of XML can and should be independent from the XML itself.
Here’s some pseudocode for the rendering of an XML document into HTML:
html = '<html><body>'
for node in document.find( 'post' )
title = node.find( 'title' ).text
descriptionNode = node.find( 'description' )
postDate = descriptionNode.attribute( 'date' )
descriptionText = descriptionNode.text
html += '<div>'
html += '<h1>' + title + '</h1>'
html += '<p>' + descriptionText + '</p>'
html += '<p><em>' + postData + '</em></p>'
html += '</div>'
html += '</body></html>'
render(html)
While this is straightforward enough in the trivial example, it falls apart when parsing large, complex documents. Consider now the XSLT equivalent:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0">
<xsl:template match="/">
<html>
<body>
<xsl:apply-templates />
</body>
</html>
</xsl:template>
<xsl:template match = "post">
<div>
<xsl:apply-templates />
</div>
</xsl:template>
<xsl:template match = "title|description">
<p><xsl:apply-templates /></p>
</xsl:template>
<xsl:template match = "content">
<p><xsl:apply-templates /></p>
<p><em><xsl:value-of select="@date" /></em></p>
</xsl:template>
</xsl:stylesheet>
Although the trivial example is longer in terms of characters, there are numerous benefits to this approach.
- The transformation is externalized. If you decide that all post divs now need a “post” class, you don’t need to recompile, and you know exactly where to make the change.
- Presumably, your XSLT editor can validate XML, or at least tell you when you’re missing a closing angle bracket or two. Most IDEs will not see unclosed angle brackets within strings as a problem, so in you get a proper environment in which to craft your output HTML. Sure, you could use an XML library that hides this implementation from you, but you still run the risk of missing an element or forgetting to append nodes to one another. This wastes time. With a XSLT document, you can very clearly easily about your output before testing. This emphasizes another issue.
- Good XSLT editors will let you quickly and easily run XSLT against XML. Using oXygen, I was able to develop the above document in under a minute. Actually testing manually-manipulated XML, on the other hand, takes much more time.
All of this said, there are still reasons to avoid XSLT in certain situations. All browsers do not support XSLT, and there are few XSLT 2.0 processors at the moment. Ergo, you must perform your transformations on the server, rather than on the client, but you should probably be doing that anyway. Furthermore, maintenance programmers will need to know XSLT to debug and extend your application, so if you’re worried about limited knowledge handling your software, it may be best to simply avoid XSLT altogether.
I’ve quickly found that XSLT is often the right tool for the job, however, so it would be a sin to not learn enough of the technology to recognize when its applicable and when it isn’t. Don’t craft your HTML by hand, but only use XSLT when it’s appropriate.