An apology to XSLT

I have to admit to thinking that XSL was something of a waste of time a while back. I’ve changed my mine and wanted to muse about why.

XML is simple enough to jump right in, and a few years back it had a big enough band wagon to mean jumping on was pretty much required. I think in hindsight, at least in my mind, alot of this was just a little gratuitous. XML abstraction layers, XML content management systems, SOAP, etc.

I’d often seen XSLT as the template layer in an XML based content management system and after several looks went back to using light weight systems that made sense. The idea of going from a database to XML then outputting HTML via XSLT just made me wonder why. The rationale that you could then output it as anything (WML, PDF, whatever) was very nice, but rarely actually realised from what I saw, and easy enough to do with any half decent templating system. You also always seemed to need more XSLT that it looked like you should.

Ruby on Rails even wore as a badge of honor that it didn’t need to do any XML pushups to deal with configuration. And even those with a penchant for Java seem to have problems with using XML as a programming language.

Of late though I’ve been back playing with APIs, many of which produce XML in one way or another (whether that’s RSS, Atom or some custom format), and XSL actually comes in pretty handy here for just thowing around content. I did some work with a Google Mini too using XSLT and their are some interesting tricks with Microformats to boot. I haven’t listened to the podcast yet so I’m just guessing at the moment but I could see Drew’s “Your website as your API” talk at the recent WSG meeting making use of XSLT?

So, I think I might have changed my mind a bit. XSL, I think, is going to be a useful skill to have in your toolkit in a world of microformats and APIs. The W3Schools XSL tutorial is a pretty good starting place if you’ve not used it previously at all. Thought I’d still rather use a decent templating engine for site rendering tasks.