The eXtensible Stylesheet Language (XSL) is a family of transformation languages which allows one to describe how files encoded in the XML standard are to be formatted or transformed. XSL is designed to be data driven and strongly encourages the Inversion of control design pattern. There are three languages in the family:

1. XSL Transformations (XSLT): an XML language for transforming XML documents
2. XSL Formatting Objects (XSL-FO): an XML language for specifying the visual formatting of an XML document
3. the XML Path Language (XPath): a non-XML language used by XSLT, and also available for use in non-XSLT contexts, for addressing the parts of an XML document.

Source: Wikipedia

In a nutshell, XSL can be used to transform a plain XML document into a full-fledged HTML document. One thing I really like about XSL is that the processing can be done either server-side or client-side. Most modern browsers understand XSL and do all the dirty work for you, leaving your server to do other, more important, things. Not only that, but if you send the XML to the client for processing, then you have the base of your API already done.

But the best part is how modular you can make the caching. Here’s how I do it:

1. If the data is cacheable it gets saved to disk in an XML file. Queries are only done to the SQL server for this data if the cache file doesn’t exist or has expired.
2. If it’s not cacheable, insert it into the cached XML document on the fly.

Then the XSL document handles the rest. I can’t think of any simpler way to do it.

However, there are downsides (when aren’t there?):

• IE has notoriously bad support for XSL (of course).
• PHP has XSL support natively in PHP5, but PHP4 requires a PECL library (I can’t find the extension on PECL for some reason).
• More syntax to remember
• The only good documentation I’ve come across is the specification itself. W3Schools, which usually has a pretty decent overview, I found lacking.
• Most variable processing has to be done before you transform the XML. It is possible to use variables in the XSL itself, but it is very limited.
• Javascript does not work on the XML document itself, just the generated source. This means if you use AJAX to grab eg. a list of languages, you have to either do the transformation server-side or in the Javascript itself. Thankfully, Google has an excellent Javascript library to do XSL transformations! Some browsers (Mozilla is one I believe) also have built-in XSLT support in Javascript.
• Unless you do the transformation on the server-side search engine crawlers will not be able to index your site. Of course you could set it up to only transform server-side if a crawler comes.

Now I ask: why don’t more sites use XSL? I know I’ll be building most of my sites in the future with XSL, the benefits far outweigh the downsides in my opinion.

Update: I completely forgot to mention a very important downside. I bolded it in the list.

The plugin was originally written by Victoria, but she gave us permission to release the updated version here. The plugin was modified by Jonathan to include tinyurl.com’s API as part of the Twitter updating.

We have some other great ideas for Wordpress plugins already coming along and will be releasing them in stages. Expect some new plugins to come out within the next few weeks.