Publishing XML to the web with XSLT: a replacement for the presentation layer


Most web APIs and data feeds are built to consume and produce XML data. RSS, SOAP, REST, ATOM, AJAX, web-services, indeed, even XHTML itself is a form of XML. If you publish anything to the web you’re probably publishing XML in some form or another. Many web developers work with some flavor of XML every day.

However few have heard of XSLT, a standard language adopted by the W3C a decade ago for styling XML data for user consumption. XSLT, or XSL Transform, is a real language, part of XSL, the XML Stylesheet Language. XSLT is a tool for reformatting XML data, literally an XML stylesheet. This powerful language lets you convert XML data into almost any other XML structure you could imagine, including completely valid and functional XHTML.

Simply put, if your web application has been built to produce XML for feeds or APIs, then you do not need to build another set of logic to make a web version. You can let web browsers hit the service, just as you would for feeds or APIs. Just create an XSLT and link it from your XML document. All modern browsers will render the XSLT and display it as a normal web page.

The most famous example of this technique in action is the World of Warcraft home page. Blizzard publishes a minimum amount of data in a XML document which includes a reference to an XSLT stylesheet. The XSLT takes this minimum of data and uses it to build the XHTML document in the users’ web browser. This means that instead of having a complicated and slow CMS solution they can serve the entire (very high-traffic) home page from flat text files. When they change the content, all they need to do is publish the tiny XML file with the new data. When they want to change the look and feel they simply change the XSLT file.

This provides a nice level of abstraction between the data and the layout. Your application can focus on data, leaving the work of presentation to the XSLT.


This technique may not be particularly well suited to your average web page, such as a company web site. Most standard web sites have no need for XML, so there is no structure to build or maintain it. But for a web application where you are going to be dealing with a lot of XML this is a great solution.

I would also argue that all XML feeds and APIs should have an XSLT stylesheet so they can render in a more user friendly view to people who want to open them directly in their browser. So if your API accepts search queries why not use an XSLT to format the results in a user friendly browser view, and add a little search form at the top.

Anywhere you send XML to the internet there is a good reason to attach an XSLT.


Using XSLT to support and render your XML data can have many huge advantages, especially for a high-traffic web application.

Faster development. Why build a whole new layer of logic and functionality? You can work on making the best XML data returns and use XSLT as your visual layer.

Less server load. Scripting a whole web site on top of your current data layer adds overhead. Save the servers, publish your data directly with a flat text file and let the browser handle the heavy lifting.

More maintainable. XSLT is basically a template. I’ve mentioned this before, but I love templates. If you want to change the look and feel of your application all you have to do is modify the XSLT files. Once you’ve gotten proficient at XSLT you will find that in many cases it is easier to modify.

Browser support

All modern browsers support XSLT, even updated version of IE6. The original vanilla version of Internet Explorer 6 used theĀ Microsoft XML Core Services (MSXML) 3.0 processor for its XSLT engine. This version of the MSXML processor didn’t support the full XSLT 1.0 specification released by the W3C, it only partially support an antiquated draft. It was also simply terrible in every way. Say “MSXML 3” to an old XML guy and he’ll probably adopt the fetal position and begin rambling incoherent nonsense about the horrors he’s experienced.

Fortunately, it is exceedingly rare to find a copy of the original IE6 out in the wild. If the user has updated Windows, installed a service pack, or installed the Microsoft Office software, then their version of IE6 has been updated to use the MSXML 4.0 processor. MSXML 4.0 and up have excellent support for XSLT and are very fast at rendering it.

I don’t believe that you should ever have to worry about browser support issues. Original IE6 is theĀ  exception, and like I said, it is very rare to find such a version of this browser out in the wild today. IE5 and earlier, as well as Opera 8 and earlier have no support for XSLT, but both of those have been deprecated by their creators.

W3 Schools has a good rundown on XSLT Browser support.

SEO implications

The impact of the XML/XSLT system on search engine rankings hasn’t been very well researched. Google seems to be able to process XML/XSLT pages just fine. They see the rendered content in their index and will display results based on that content.

Honestly, I can’t say for sure if this system will impact your search engine rankings in a positive or negative way. I’ll do some experimentation the next time I get the chance.


If you already work with XML then diving into XSLT shouldn’t be that hard at all. Authoring XSLTs is notably more technical than simple HTML, but if you’re building a web application that produces XML then you must already have a good amount of technical prowess.

There are plenty of good tutorials for XSLT out there, a quick google search will give you all of the resources you will ever need to become an XSLT master. But I will provide one example XML with and XSLT to show you what it looks like.


Any XML document that is valid can be rendered with an XSLT. The only item that you will need to add to the XML document is a stylesheet declaration pointing to the XSLT file (or files) that it should use for use rendering.

Immediately after the XML declaration you will add a line of code that looks like this:

<?xml-stylesheet type="text/xsl" href="/path/to/your/xslt_file.xsl"?>

Let’s use the following XML data for this example, a search result for the string “XSLT”:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="layout.xsl"?>
		<class id="12" name="XSLT 101">
			<datetime>Feb 1, 2010 8:00pm PST</datetime>
			<description>A basic introduction to XSLT.</description>
			<teacher>Steven Benner</teacher>
		<class id="18" name="Advanced XSLT">
			<datetime>Feb 2, 2010 8:00pm PST</datetime>
			<description>Advanced XSLT techniques and concepts.</description>
			<teacher>Steven Benner</teacher>
		<class id="35" name="XSLT History">
			<datetime>Feb 1, 2010 2:00pm PST</datetime>
			<description>The history of XSLT.</description>
			<teacher>Steven Benner</teacher>


There is a whole language and syntax that powers XSLT, I wont bother trying to write a full guide here. I just want to provide you with a basic example to show you how it works.

One important item to note is that XSLT selectors use XPath statements to target data. XPath, or XML Path statements treat XML data like a directory structure. Node values are targeted like a directory (e.g. parentNode/childNode), attributes are selected using an “at” sign (e.g. parentNote/@id).

This is what the XSLT for rendering it as an XHTML document would look like.

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="">

	<!-- set output mode as html -->
	<xsl:output method="html"/>

	<!-- template that matches the root node -->
	<xsl:template match="searchdata">
			<title>Search Results For <xsl:value-of select="query/search" /></title>
			<h1>Search results for <xsl:value-of select="query/search" /></h1>

			<!-- results table -->
			<table border="1" cellpadding="5">
					<th>Class ID</th>
					<th>Date &amp; Time</th>
				<!-- run the template that renders the classes in table rows -->
				<xsl:apply-templates select="results/class" />

	<!-- template that matches classes -->
	<xsl:template match="class">
			<td><xsl:value-of select="@id" /></td>
			<td><xsl:value-of select="@name" /></td>
			<td><xsl:value-of select="teacher" /></td>
			<td><xsl:value-of select="description" /></td>
			<td><xsl:value-of select="datetime" /></td>


This would render the following view in your browser:

Rendered XML with XSLT

Don’t believe me? Take a look at this live demo.

Alternative implementation

You can use XSLT on the server side just as easily as in the browser. If you simply cannot publish an XSLT for the web you can still use this technology as a template engine. You can build a separate presentation layer that interacts with your XML web service then run the transforms on the server side. Users will never see the raw XML.

Be warned however, XSLT is not the fastest template engine ever made. You will lose the speed benefits of publishing the XML/XSLT directly to the browser. For pure speed, a properly optimized PHP or .NET web application will out-perform it.

In .NET you have the XslCompiledTransform class, and in PHP you have the XSL extension.


The example I provided above is just the most basic functionality XSLT has to offer. I hope you can at least get an idea powerful this technique is and how much time it can save you on your next (or current) web application.

There is so much value in separating your data layer and presentation layer. Maybe XSLT is the solution to all of your problems, maybe XSLT is completely useless to you. Either way, it is another valuable tool in your toolbox. Remember it is there and perhaps you’ll find that you couldn’t have lived without it.

Updated: Mar 7th, 2010


  1. Alejandro

    Despite the fact that many deny the use of XSLT on the client, is a technology common to the vast majority of modern browsers. It is much more compatible than EmacScript between different browsers.
    For all tasks involving static modification of a DOM based on an XML document, XSLT is faster and easier than EmacsScript. The difficulty lies in learning the declarative programming approach.
    On the other hand, I would not recommend the use of the semantics of XHTML within the XSLT style sheet. It is better to provide separate XHTML page and data (in an XML document with standard vocabulary) allowing the XSLT stylesheet to make the connection.
    In example

  2. If you’re building an XHTML document anyway I don’t see the benefit of using XSLT to modify that document. You’re loosing the abstractions between data and layout and risking backwards compatibility issues with IE6. Only XHTML 1.1 specifically allows (and requires) XML declarations, but IE6 does not support XHTML 1.1 because of the XML declaration. The first line of any HTML document must be a DOCTYPE statement or IE6 reverts to quirks mode.

    All modern browsers support XHTML 1.1, but IE6 is still too common to ignore especially for a business. (Granted, this site doesn’t work with IE6)

    The only place XSLT can be reliably used if you need to support old browsers is on an XML document.

  3. Alejandro

    I have been misunderstood. In your example the XSLT stylesheet has embedded XHTML semantic. What I propose is to separate transformation (XSLT) from layout page (XHTML).
    So, do not lose any level of abstraction. In fact, we are adding a level: the connection by using XSLT.
    XML (data, preferably in a standard vocabulary and not one designed ad-hot) – XHTML (layout for browsers) – XSLT (bindding) – and of course, CSS (design) – and EmacScript (behavior, if necessary)
    In this way, the whole design of the page for browsers can be done without taking into account the type of linkage with the data, taking full advantage of WYSIWYG editing with any software (not tying to only those that allow the addition of XSLT ), and allowing the separation of concerns in the development team.
    Regarding IE6, for any XML document to be provided, the browser will remain in standard mode. In fact, the problem is with IE7. If the document resulting from the transformation does not have a DOCTYPE declaration, IE7 interprets the CSS stylesheet like IE6 (losing the ability to use the hover pseudoclass on any element, for example)
    Check out my site and see how all these minor problems are solved.

  4. Oh I see, yeah I guess I didn’t quite understand how you were abstracting the content. That’s an interesting approach. Thanks for the information!

  5. Hi Steven,

    great article, I love your promoting the benefits of XSLT.

    When we started the development of our model-driven CMS, we decided to go for XSLT rendering according to the benefits you mentioned above. If any of your readers here like to play with XSLT rendering: I encourage you to donload the free evaluation license (productive use may need a full license) of at and use it as a test-bed.

    I somewhat disagree with your statement on rendering performance. is getting more and more popular here in Germany and actually many customers praise its extreme speed – not only wrt to project development and training but especially wrt to web-page delivery. Take a look at which is a good example of a driven site with some traffic and a lot of dynamically placed contents.

    Actually I did a study comparing Alexa’s average load times of the product sites of the ~40 CMS systems featured by the WCM report of the Real Story Group It covers all the big brands, and most of them are not using XSLT rendering technology. Actually there was only one CMS featuring a similar speed like Therefore, I would not sign that the delivery speed of XSLT poses any handicap in real-life CMS products.

    Keep that XSLT flag flying!

    Regards from Germany,

  6. Mitch Stokely

    This is a very good article. We need more developers explaining how and when t use XSLT driven web sites, because I think alot of young web kiddos have bought into the notion of the ECMAScript solutions……creating these gigantic libraries of (often) compiled or scripted Javascript that they use to not only simulate some level of interactivity but then abolish the markup model of the web and use scripting API’s to move data back and forth over the wire between the page and the server. This effectively ruins the whole request-response web model as well! What a HUGE mess these kids are making of the web now!

    I say we need to drive home the importance like we did 10 years ago, of the XML and XSLT model, whereby now, we have a generation of browsers that are fully capable of supporting XSLT on the client. Which proper caching and content design, we can remove most of the need for these JQuery and scripted libraries and have kids start using XSLT. The promise is not only faster deliver, more reliable, repurposable content, but also smaller data packets between client and server! No, as content moves between devices in XML, we can plant custom XSLT and CSS text files on them and as users interact with the pages, post back XML and rely on cached XSLT and CSS as needed. One can begin to remove scripts and rely more on XML, as it should be. This is not to say API’s script libraries and “web app” systems cant be delivered to clients and are not needed. But it makes what is becoming a fat chunky API layer a much slimmer layer, as it was in the 1990’s and needs to be again today in correct web page architecture.

    The whole purpose of HTML and HTTP and the model behind the protocols and frameworks, and the new XML and XSLT model is just abstraction of layers…..its to have the whole thing run better and faster with less complexity and easier maintenance and delivery of content over the Internet. With new smart phones and many much smaller and “liter” wireless devices to come, we all need to move to the XML and XSLT model here soon; where delivery of data, not scripts and broken API junk, is all these devices will need to relay. Otherwise the “script kiddies” will end up building one giant web javascript app that replaces the browser entirely and we are back to not only the “desktop app” model from the 1980’s again, but we are building another API house of cards that hackers have free reign over. Lets all pound away online about the need for education in basic HTML, XHTML, XSL, XML, and XSLT designs….and less Javascript!

Leave a reply