XSLT is considered the normal mechanism for transforming XML for viewing in a browser, but it can make software more difficult than it needs to be. This article discusses some of the experiences and common issues with XSLT. If you're using CMarkup and you just want to get on with the job of processing XML for display in a browser, see Transformation Using CMarkup for a better way, since CMarkup does not support XSLT.

At first it sounds great to have a mechanism for querying and sorting the data from an XML document into a page that can be viewed in a browser. And it would be great if there were no serious performance and flexibility drawbacks. But the truth is that XSLT comes with overhead and architectural constraints that make for big headaches down the road.

If your XML data is taken from a database it is best if your design takes advantage of the speed of the database for querying the specific data and sorting it in the desired order, even if you use XSLT to display the data. So XSLT querying and sorting capabilities are only compelling in a limited set of situations i.e. when you need to provide multiple subsets or orders on the dataset that MUST reside in an XML document rather than a database. This may be common in the literature about XSLT, but not in real software requirements.

What draws most people to XSLT is probably the ability to design a page that includes, somewhere in the middle, a format for a table row that will be repeated for each record in the dataset. But in the XSL format, the page cannot be viewed in a normal browser, and it must be developed with a stricter cousin of HTML called XHTML. It would be more direct to just make your normal HTML page with bookmarks in it that you could replace with values or pieces of HTML generated programmatically. Tools using this direct approach would require very little explanation, but buying into the XSLT framework appears at first to offer advantages.

One exciting prospect of XSLT is its support in the browser allowing transformation on the client rather than the server. However, this is exciting only in concept, not in practice. One consideration is offloading the work of formatting from the server to the client, but if scalability is a major concern then it would be advisable to reconsider your design holistically. XSLT creates new performance issues that you might never encounter in more direct solutions. Most importantly though, XSLT has varying support in different browsers and versions of browsers making client side transformation an unreliable and problematic design choice.

The transformation instructions for XSLT are programmed in an XSL Style Sheet which is an intimidating XML document format. A style sheet is a declarative way of describing how the result file will be generated. And using this unfamiliar declarative paradigm, you are limited to the features provided by XSLT. Not everything is possible, and many of the things that are possible you will never figure out how to do. XSLT has created an industry of its own around learning and re-engineering everything you already knew how to do in your familiar procedural language.

Todd developed a sophisticated web application around XSLT that I tried out and it works well; so his warning comes despite having successfully implemented this architecture. Other problems he mentioned are serious (known) performance issues in MSXML 3.0 XSLT, and scaling problems even in MSXML 4.0 XSLT despite not using it for sorting or subquerying the XML dataset. Once you have invested time in XSLT and gotten it to do what you want, you may have an even greater challenge tweaking the performance which requires an understanding of the inner workings of the XSLT implementation.

Thanks for speaking up for XSLT. Certainly it is the established means of XML transformation, successfully utilized far and wide. My critique attempts to warn the uncommitted mostly on the basis that it is an indirect way of attacking the problem that takes some time to get your head around. I recommend a more direct approach.

In Are standards around XML, XSLT and XSD overrated?, Drazen Dotlic writes about a problem that could be "almost trivially solved with XSLT". My response is that XSLT can never be as "trivial" as a CMarkup solution in a C++ project because XSLT involves an additional language (you may know it but does the next developer who comes along?), a separate stylesheet file that must be integrated into the solution, and a dependency on an XSLT component. All three of these are non-trivial complications. But anyway, Drazen has a good writing style and discusses some interesting examples. In response to the CMarkup article Transformation Example: Apples to Oranges, Drazen provided some in-depth XSLT alternatives and afterwards had the following to say:

CMarkup targets developers who realize the benefits of avoiding component dependencies and keeping XML processing simple. Because of these inherent advantages, simply showing that the CMarkup/C++ alternative to XSLT is more straightforward is enough to demonstrate its suitability. You may also be glad you avoided XSLT if your project ends up involving the iterative processing or special data type manipulation that Drazen refers to. However he also recommends an approach that combines XSLT with other languages via extension functions from the XSL. I guess he feels the integration and debugging hassles of combining multiple languages is worth it in some cases. The question that needs to be weighed is whether to avoid the potential limitations and hassles of XSLT altogether.

Certainly there are situations where XSLT is the right solution, particularly in a language or on a platform where CMarkup is not available but XSLT is. :)