The XHTML you receive when browsing this site is generated dynamically using XSLT. There are no exceptions. Even data entry forms use this appraoch. This is not the first site I've built with XSLT. The Delphi newsgroup front end,, uses a similar appraoch (although it is based on an older versions of the architecture powering this blog).

What is XSLT?

In the early days, you could display an XML document in a browser by attaching a CSS (cascading style sheet) to it. For each XML tag you could (and still can) specify a font and other formatting options. This produces a rather flat output, with all of the XML nodes listed and a rther rigid display. This is why the W3C come up with the idea of an extended stylesheet language, which has two versions, transformations (XSLT) and formatting objects (XSL-FO). An XSLT document (which is an XML document itself) allows you to generate an XML or HTML document from another XML document, by transforming nodes into other nodes.
Based on XPath for nodes selection and organized around templates (which keep reminding me of LISP list processing), XSLT has a tremendous power, most often unexplored. After 3 years of extensive XSLT usage, I keep learning new tricks. Truly, it is not a language in terms of programming language, but templates have a version that looks like a function call, allow for recursion and a sort of inheritance (or modal processing).
There are many XSLT processors out there. Right now, I'm mostly using libXSLT (along with libXML) on both Linux and Windows. Using it from Delphi is not a big problem thanks to the Libxml2 for pascal project. Notice, by the way, that I do all XSLT processing on the server: relying on the browser for the transformation is very troublesome due to many imcompatibilities (there are 3 different versions of MSXML2 out there, and IE might not even pick the last one if a machine has more than one installed).


Now the question is why to favor the use of XSLT over other web technologies.
One big reason is that XSLT can be used along with most other web technologies: Delphi's WebBroker and WebSnap (see my books for examples), ASP.NET, Java, Python, and most other solutions. Even JavaScript has XSLT processors. So XSLT can be considered a fully cross-platform and cross-programming-language layer. This means that even if learning it is not trivial, your investment is likely to be preserved.
The most relevant reason, though, is that AFAIK XSLT is the only technology providing a real and complete separation of the presentation layer from the business logic. I know ASP.NET and many other technologies claim the same, but the difference is huge. To obtain complex output with other technologies you have to reply on compiled components. When you go from a table view to a list-based view you need to change your source code (switching the component) and recompile your application. You can, of course, generate everything in a script, but this is hardly the suggested option (and the more RAD-oriented one). If you write a complex script manually, than you can as well write the XSLT (and put it on top of ASP.NET, if you really like to use this technology, although you loose some of its features anyway).
The flexibility and the power XSLT gives you is really tremendous. You can do sorting, indexing, and grouping of data in the presentation layer. You can change the output depending on actual values. You can combine information coming from different sources. You can use data structure information (possibly XML schemas) to drive your user interface. For example, we've built a data entry layer thatis driven by schema information. You can also generate the XSLT using another XSLT transformation.
If this is the case, you might wonder, why its usage it still somewhat limited? I can think of four reasons: no big vendor is behind it (they want you to invest on plaftorm specific technologies, you know), it had a rather steep learning curve (its processing model is hard to grasp at first), it is better suited for data display than data entry (more web sites than web applications), there are limited developer's tool (with the notable exception of Altova's XMLSpy) helping you speed up XSLT-base development.
On the other hand, recent trands (including AJAX) are pushing in the direction of XSLT. The new 2.0 specification should also add more power to the language, solving some of its current problems. We'll see. For now I'm betting on it and I'm not expecting to be disappointed...