Working on this Website, Part II (January 13, 2004)

I started to work on this website again couple of weeks ago. I've already written about the basic approach I took a year ago to write the content in XML, and generate working XHTML with XSL. All of that was working, but there were problems, namely that I was terrified of changing the XSL once it was working. I mean, there were other issues, such as the inability to nest topics (Home->Writing->Blogs), but the larger issue was that I couldn't easily change the XSL without breaking something.

Things have improved, though it is far from perfect. I've learned more about variables in XSL, as well as imports, and how I can use both to modularize the transformation better.

The cool thing I discovered, sort of to my surprise, is that variables in XSL are more than just placeholders for a single value. Or rather, I can store more than just a string in a variable. I think I knew this, but in coming back to it I've realized how cool this is. I can't explain the technical background very well (because I don't understand it), but to give an example, I can declare

     <xsl:variable name="key" value="@key" />     

which will later let me reference $key containing the attribute value @key for the current node being processed. But it turns out a variable can also hold a node-set, which means the following works as well

     <xsl:variable name="allTopics" value="//topic" />     

which means that $allTopics now holds all the elements on the current document. I can then loop over them using an

   <xsl:for-each select="$allTopics">something in loop</xsl:for-each>   

I could even restrict the topics to blogs I want to process using another variable

   <xsl:variable name="allBlogTopics" value="$allTopics[@key='blog']" />   

and, to make it better, I can now pass this variable in as a parameter to a template

   <xsl:call-template name="write-blogs">   <xsl:with-param name="$allBlogTopics" select="$allBlogTopics"></xsl:with-param>   </xsl:call-template>   

and so on and so forth. The ability to capture segments of the document tree in a variable is not only useful, but also a different way of thinking about document processing. XSLT itself serves to convert an input document into an output document. What variables let you do is to 'snip' portions of the document around while you are preparing the output. So suddenly I have this sort of clipboard of little document fragments that I can work with. Which is very cool.

Of course, there are problems. Variables in XSL are not typed, and there are no real checks that what you are doing with a variable is meaningful. Or that the variable actually contains anything. If you make a typo on your XPath in the variable declaration, you may get an error (if there is an error in syntax), but you might also just get an empty node-set, meaning that the variable is useless. Now, that might be OK, if your XPath pointed to a fragment that might or might not exist in fact. But if you expect it to be there, you may just find the little typo causes a whole section of output to be skipped.

I assume that if one used an XSL debugger this would become clear. Alas, I am not. The equivalent of a print() statement in XSL is the <xsl:message></xsl:message> command, which is cumbersome to type, not least because to show the value of an element or a variable, you need to nest an <xsl:value-of></xsl:value-of> element within it. Even with the help of my editor, this is cumbersome and ultimately, tiresome. I guess that's the right word for it: XSL is tiresome to write.

So why use XSL? In my case, as I wrote elsewhere, I wanted to separate the presentation from the content, always a noble and probably worthwhile goal. There are, of course, a number of options, but as my goal was to display a website, and since I had used XML and XSL for this purpose before, it seemed only fitting to apply it here as well. The upside is that, for the most part, the bulk of the presentation code is no longer in the pages themselves, outside of some directives for bold-face, underlining, lists, and the like. The downside is that developing the transformation for the pages in XML takes a long time, and the whole thing feels a little fragile. A small change to the XSL, a little typo, and whole sections may just disappear. And, on the whole, XSL feels mostly natural as a means of transforming XML into XHTML. The XSL actually embeds the output XML within it, so if you back away and squint a little, you get a decent idea of what will come out the other end.

And, truth be told, the fact that XSL was well-defined and has a proper specification is a bonus. There are a number of "templating" languages for web pages, but many were not, as far as I can see, developed by language designers. Which is fine, just that there are more oddities and ambiguities there than I find in XSL.

And, to sum up: XSL is a rather cool way of working with a tree-based structure like XML. Snipping little document portions just feels more natural in XSL than it does in another language with an XML library, like Java. Every language has a feel to it, and, as far as that goes, I think XSL is both interesting and, it it's own humble fashion, rather lovable.

You can comment on this on the jRoller Website site, the the host for the blog entry above.