XSLT

From Docunext Technology Wiki

Why I Prefer XSLT

Potential Problems with XSLT

XSLT can be a difficult language to work with. Its achingly functional, and not very expressive, at all. Since most applications are written in other languages (such as Ruby, Perl, or PHP), it also requires bindings to a processor, such as libxslt, so its not always easy to get up and running right away, like it can be with native templates. There are even some patents involved with XSLT technologies - I have no idea how far reaching they are, but I've been told that they are there.

Benefits of XSLT

With all that against it, why do I choose XSLT? First off, I see the fact that XSLT often requires bindings to a processor like libxslt as a good thing. Its a very high quality processor! Second of all, if for some reason, libxslt becomes unusable, there are other high quality bindings, like Sablotron, SAXON, and Xalan.

Secondly, since XSLT is totally reflexive and introspective, it could be possible to transform XSLT templates into other template languages = portability!

Other benefits of XSLT:

Its can be setup as a filter - a web server can test a source XML document for changes without having to transform the source document every time
The same templates can be used with different languages: Perl, Ruby, PHP - whatever! (There are other template engines which can work with different languages, such as Template Toolkit and Tenjin)
Its a standard - there is a canonical reference which defines how it should work
It can output content in a variety of formats: plain text, HTML, XML, and even PDF via XSL-FO

XSLT Goals

My current goals with XSLT is to make my stylesheets more flexible and portable from one application to another.

Client or Server-Side XSLT?

Other issues with XSL transformations on client side:

IE "flashy", not smooth like in Firefox on XP or OSX
Google indexes XML as data not web page
http://groups.google.com/group/Google_Webmaster_Help-Indexing/browse_thread/thread/238d97fe44b8ee5e/7399a2ea1f010d74?lnk=gst&q=
http://groups.google.com/group/Google_Webmaster_Help-Indexing/browse_thread/thread/60f33d5d38ad3eb/13e4d40560d458f3?lnk=gst&q=

Client Side XSLT

There are at least two ways to do transformations on the client side:

right inside the client - load an XML file and include an XSL stylesheet. I don't use this for a variety of reasons, except in specific situations, like in SVN servers.
Using Javascript - its not too easy right off the bat, but thankfully there are a bunch of libraries like Sarissa to make it easier. This is the way I would like to start doing client side XSLT transformations. For the most part, I would like all resulting document permutations possible with client side transformations to also be available via a server side API. I'm not sure how to do that, but I'm glad that Xpath uses a similar syntax for traversing documents as filesystems use for separating folders.

Server Side XSLT

There are a bunch of ways to perform server side XSL transformations:

With a scripting language like PHP, Python, or Perl
With a web server module like mod_transform
Many methods are supported by the awesome libxslt project (a GNOME project), including NGINX!

I use server side transformations all the time for private sites. Server side can get cached via mod_transform or NYT XSLT.

I like the idea of an XML server, which gets used by a "middleware client", curl or AJAX, and an HTML / XHTML server, where the content is output / produced by XSLT transformations. See dbrs2xml.

XSLT Processors

Cool XSLT Stuff

Xslfo - easy way to generate PDFs from XML
XSLT and SVG
XPath
EXSLT

XSLT 2.0

Version 2.0 has a lot to offer, though only Saxon currently supports it. A couple things I'm interested in:

XSL Powered Applications and Frameworks

Links