Practical XML for the Web, Chapter 5: Introduction to XSLT

This is an excerpt from Chapter 5 of "Practical XML for the Web", by glasshaus, (ISBN: 1904151086, copyright glasshaus 2002). It introduces XSLT, going through the basics of using it to transform XML on the client-side, by way of easy-to-follow tutorial examples (we have included the first three examples here). Chapter 6 of the book takes client-side XSLT to a more advanced level, and Chapters 8-11 include coverage of server-side XSLT usage.

5

Introduction to XSLT

In this chapter and the next, we're going to introduce the use of XSLT – Extensible Stylesheet Language Transformations – to format and display XML documents. In this chapter we'll give you an overview of XSLT, and how to use it in the client's browser with some real-world examples of transformations. Chapter 6 will then develop this knowledge with some more complex examples of XSLT in action. You will then learn about using XSLT to transform XML on the server in Chapters 8 to 11.

An extreme example of XSLT can be found at https://people.w3.org/maxf/ChessGML/ (you'll need the SVG plug-in from https://www.adobe.com/). Here, an XML representation of a chess game (stored as ChessGML, a standard XML vocabulary for representing chess games in XML) is converted into an SVG animation using XSLT. SVG is an XML-based standard for describing images and animations, and the XSLT stylesheet used by this site converts a simple ChessGML game into a fully-animated representation of the game being played move by move.

So what is XSLT? Essentially, it is a way of transforming XML documents into other documents (often other XML documents). When it comes down to it, XHTML web pages are just XML documents, so we can use XSLT to transform an XML document into a styled XHTML web page, and display it in a browser.

We have already seen how XML can be displayed using CSS. XSLT goes one stage further by giving you complete flexibility to change the layout of your content. Furthermore, it allows you to define rules that not only alter the design, but can also add, change, and remove elements of the content, if appropriate. So if you want to exclude some content from a page based on your XML, XSLT can automatically strip out this content for you. Conversely, XSLT can add in content or generate new content based on the existing XML document, such as headers and footers. You can go further still with XSLT, and convert your content into alternative formats such as RTF (Rich Text Format) documents and CSV (Comma Separated Value) files for Word and Excel.

Although XSLT is very powerful, CSS is often better for simple tasks. We're certainly not suggesting that, having just read the CSS chapter, you throw all of your CSS knowledge away and use XSLT instead. It is often best to use a combination of CSS and XSLT to achieve the look we want.

We will be focusing on the most practically useful aspects of XSLT, and by the end, you should not only have an understanding of how to use XSLT, but more importantly recognize why XSLT is useful and know where to use it.

Server-side versus Client-side

There are two approaches to applying XSLT to your XML content. You can perform these XSLT transformations server-side on your web server, and serve up the resulting HTML web page to a browser. Chapters 8-11 of this book will cover server-side XSLT transformation in detail.

The other way to use XSLT is to send a source XML document and an XSLT stylesheet to a browser, and ask the browser to apply the XSLT transformation for you. Here we will learn which browsers support this client-side application of XSLT, see what benefits it gives, and see some examples of client-side XSLT in action.

Browser Support for XSLT

Given the inconsistencies between HTML support in the different browsers, it should come as no surprise that they offer varying support for XSLT as well. The good news is that through careful use of XSLT it is possible to achieve support by more than 95% of the browsers on the market while still providing readable content for the rest.

There are only two different XSLT specifications to worry about. The recent browsers with XSLT support (Internet Explorer 6, Netscape 6+, and Mozilla) all support the XSLT 1.0 standard – the specification for this is available online at https://www.w3c.org/TR/xslt. Unfortunately Internet Explorer, in versions 5 and 5.5, as well as PocketEI, support an earlier form of the XSLT standard – the XSL Working Draft (see https://www.w3.org/TR/1998/WD-xsl-19981216, although only the transformations section of this specification is implemented). We'll see how to support both soon.

The picture is muddied further because the older IE browsers can be updated to use more recent XSLT processors. In practice only a tiny fraction of users, mostly developers, will have updated, and they will have almost certainly have upgraded their actual browsers by now.

Throughout the rest of the book, to make things less confusing we'll be referring to the XSL Working Draft implemented by IE 5.0 and IE 5.5 as XSL-WD, and the full version of XSLT 1.0 supported by IE 6, Netscape 6+, and Mozilla as XSLT 1.0. XSLT 1.0 is also the version of XSLT implemented by the server-side XSLT processors described later in this book.

For the most part, XSL-WD is a subset of the functionality available in XSLT. For a list of the exact differences between XSL-WD and XSLT, see the table at the end of the chapter, as well as https://www.zvon.org/xxl/XSLTreference/Output/index.html. Most browsers on mobile devices do not support XSLT, with the exception of the Pocket PC, which supports XSL-WD.

The examples in this chapter will work across all of IE 5+, Netscape 6+, and Mozilla, with only very slight changes for XSL-WD browsers. Chapter 6 will introduce some of the features of XSLT 1.0, and also some of the Microsoft-specific extensions.

As explained in Chapter 3, even if the client doesn't support the level of XSLT that you would like to use, you can still get many of the benefits of XSLT by using server-side script to do browser version sniffing, and then styling on the server for older clients and sending XML/XSLT to the browser for newer clients.  The same XSLT 1.0 stylesheet can be used server-side and client-side.

Example 1: Saving Bandwidth by Using XSLT for Headers and Footers

Let's start by taking a normal web page, and seeing how we can use XSLT to add some standard content to the page. In this example, we'll add a header and footer to a simple page of XHTML.

All of the examples in this chapter can be downloaded from the glasshaus web site at http://www.glasshaus.com. The downloadable versions have additional comments so you don't need to keep referring back to the book as you read them.

The benefits of doing this in XSLT are as follows:

·          We only need to store one copy of the header and footer code to cover every page on the site, making it easy to change them globally without editing every single page.

·          Users only need to download the header and footer XSLT code once, even though they are used on every page in the site. This can give bandwidth savings, which is important if your service provider charges by the megabyte, or if you are supporting modem users.

·          Server processing is reduced as all the work is being done on the client.

How else could we do it? We could manually add the header and footer to every web page, but this would result in a site maintenance nightmare, especially for a large site. The other alternatives are as follows:

·          By using Server-Side Includes (SSI) to include standard header and footer content on every page.

·          By using a scripting language (such as ASP, PHP, or JSP) to generate web pages with the header and footer included.

Although these methods share the first advantage of only storing one copy of the header and footer, they do not reduce the bandwidth or server load.

Take it From the Top

Here's our starting XHTML page, dinosaur.html. It's nice and simple, not very pretty, but functional (don't worry: we'll beautify it later):

And here's that code in action:

(Well, we did say it wasn't that exciting.)

Let's spice up our page by adding a header and footer. We could of course just add some extra header and footer XHTML into our page and do things the old-fashioned way, but that wouldn't give us the benefits we describe above. Instead, we'll add an extra line to the top of dinosaur.html, and save the resulting code as dinosaur_1.xml:

This new line performs one very important task: referencing our first XSLT stylesheet file, headerfooter_1.xsl. The rest of our XHTML stays the same.

During this chapter, we will encounter slight differences between how various browsers deal with stylesheets. In a minute, we'll learn a useful trick to specify different stylesheets for different browsers, but for now we'll keep things simple and just specify headerfooter_1.xsl.

You may have spotted that our new page has an .xml extension rather than .html. There's a reason for this. In order to start using XSLT to transform our page, we need to be sure that the page is well-formed XML, rather than just any old HTML we've chucked together. Our new page is in fact XHTML, as introduced in Chapter 2 – we therefore give it the .xml extension.

An Aside on XHTML Namespaces

If you're familiar with XHTML, you may have realized that the page above is not strictly conforming to XHTML. It is lacking an xmlns attribute in the <html> root element, and there is no DOCTYPE declaration at the beginning of the document.

An XSLT stylesheet will normally act on elements in the default namespace. If the xmlns attribute was present in the source document, then all of the document elements would be in the XHTML namespace. This means that the template match in the stylesheet for the <body> element would have no effect – it would be looking in the wrong namespace for the match.

In order to make the match correct, we need to tell the stylesheet about the XHTML namespace. Just as in the source document, we do this with an xmlns attribute, giving the URI for the XHTML namespace. The amended xsl:stylesheet element would look like this:

Having done this, we can now refer to the body element as html:body, thus:

The reason for leaving this out of the example is to keep it simple – and most of the time, it's enough to use the default namespace.