..and why and when to use other technologies like JSP, ASP, PHP, Python, Servlets, etc.

In order to be able to determine why and when to use XSLT, it might be helpfull to make a theoretical side-step.

XSLT is based on the principles of Functional Programming. John Hughes has written a good paper on the essence and strengths of Functional Programming.

In short, the basics of a Functional Program are (in between brackets the corresponding XSLT functionality):

• the program consists entirely of functions (templates in XSLT).
  • functions receive input and deliver output (XML in, XML/HTML/etc out).
  • a function call has no other effect than provide a result; there are no side-effects and thus order of execution is irrelevant.
  • the program itself is a function (XML in, XML/HTML/etc out); its ouput can serve as input for another program (XSLT styelsheets can be chained).
  • functions are defined in terms of other functions.
  • bottom level functions are language primitives.
  • it supports "higher order functions": functions can be "glued together" in recursive patterns, one function can have another function as its argument; simple functions are combined to make more complex ones. (This is not an obvious feature of XSLT, but Dimitre Novatchev has shown that it can be accomplished by way of template references).
• the program is "declarative": it does not contain assigment statements, so variables, once given a value, never change. (XSLT variables and parameters are declarative).
• it supports "lazy evaluation", a method of evaluation to run functions as little as possible. (not supported in XSLT, but it can be simulated, also shown by Dimitre Novatchev)

Thus a Functional Program essentially consists of black-box modules. The goal in developing a Functional Program is to create smaller and simpler and more general modules.

Although there is some discussion as to wether XSLT is a trully Functional Programming language, the above rather theoretical side-step to Functional Programming will help in determining in what cases XSLT will be a good choice, and when it is better to use other technologies like JSP, ASP, PHP, etc., which are procedural and "imperative" in nature (which means that variables can be changed during the execution of the program, causing side-effects and therefore requiring a predefined order of execution).

XSLT requires input to be in the format of XML. This might seem a disadvantage at first (not shared by JSP, ASP, PHP, etc), since you might have to build a custom transformation layer on top of a database for instance, to produce the desired XML. On the other hand, XML is emerging as the de-facto data standard, so having your content in XML format might be required sooner or later (for any sort of data interchange).

Let's assume that your content is already in XML and that you want to build a website, thus having to transform the XML into HTML. Is XSLT the best choice in this scenario?

The strength of XSLT is the ability to modularize the transformation process of XML into HTML. In order to make best use of this, the problem domain must be such that it can be divided in ever smaller, more and more generic components. With respect to building a web site this means that there must be a limited set of XML that can be expected as input, and that there must be some common look and feel to pages, otherwise the variation in the required transformation is too big and modularization will become too tedious. Thus a site where every web page has to be different with little or no commonality between pages will most likely not benefit from the strengths of XSLT transformation. Dito for web sites where the content for every page basically has its own XML structure and there is no common structure shared by pages. In both cases you would basically be using XSLT to write a procedural program; possible, but why should you? In these cases, simply plain HTML from the start or -if there are dynamic elements on the site- JSP, ASP, PHP, or any of the other technologies might be a better choice, since they generaly perform better than XSLT.

XSLT really shines when the input XML is as generic as possible, consistent between pages, and the web pages have a relatively consistent look and feel (at least where it comes to elements on the page). The use of a content management tool which creates XML according to a predefined DTD and the use of an API that transforms data from for instance a catalog database into XML according to a predefined DTD will take care of the first requirement for using XSLT. The design of a web user interface that is consistent will take care of the second requirement.

Some concrete examples:

• Consider an informational web site (like the NMS site); content is mainly static editorial text, highly structured, and the web site has a very consistent look and feel.
  -> ideal candidate for XSLT. If a site like this is mainly non-dynamic in nature it is beneficial to pregenerate the HTML pages and cache them on the web server, in stead of rendering them real-time.
• Consider a catalog site like an online store, or a classics books catalog; content is stored in a database and thus highly structured, and transforming this into XML is straightforward, there are many web pages that fit into one or more display templates.
  -> good candidate for XSLT, especially if there are many categories of products, with shared XML elements (meaning that for instance the title of a book and the title of a video are both represented as <title>; not as separate <booktitle> and <videotitle>).
• Consider an artist's personal web site with a very creative and non-structured look and feel.
  -> no good candidate for XSLT, since it is likely difficult to find commonality between the pages.

This gives an answer as to when to use XSLT. For the why, we have to look back once more at the concepts of Functional Programming, outlined above, because the strength of XSLT over all the other common technologies like JSP, ASP, PHP, etc, in my opinion is the fact that it is based on the principles of Functional Programming. XSLT allows for the division of a problem domain in ever smaller and smaller independent components that simply have an input and a output and don't cause any side effects. This allows for the creation of components in a nested structure that, the deeper one gets in the structure, the more generic the components become. These generic components then can become building blocks of other new functionality. Components can be tested separate from each other, and because of the clearly defined input and output they can easily be re-used. An other strength of XSLT is that it allows for a complete separation between content, presentation and styling.