XSLT: The X factor in transforming XML

XML is the standard for representing data, but applications need standard ways to manipulate the data contained in an XML document in order to make it useful in business applications.
Written by Tim Landgrave, Contributor
As predicted by most industry pundits, XML is the defacto standard for representing data as it flows between two systems. But applications need standard ways to manipulate the data contained in an XML document in order to make it useful in business applications.

The XML manipulation language is called eXtensible Stylesheet Language Transformations (XSLT). The premise behind XSLT is simple: I have an XML document in a format that’s useful for my systems, but you may need the XML document formatted differently in order for your system to consume it. Rather than requiring my developers to create different XML documents for each potential consumer, I can create a single base document and then apply formatting templates to “transform” my XML document into an XML document that the client's system can consume.

In order to make it happen, however, it’s critical to understand the fundamentals of XSLT and then examine ways you can use XSLT in developing your business applications.

The difference between XSL standards
First, let’s discuss the difference between XSL and XSLT, as this is a confusing topic for some. XSL was a draft recommendation that defined a programming language that transforms XML documents into different formats by embedding the language in a stylesheet. Since that original draft, XSL has been split into three different standards:

  • XSLT: For transforming XML documents
  • Xpath: For navigating XML documents in programming
  • XSL-FO: For advanced formatting of XML documents for display

Most XML development systems focus on creating well-formed XML documents and using XSLT stylesheets for transformation.

As XSLT is capable of doing the majority of the formatting required in a transformation, XSL-FO has been relegated to very specific formatting duties and, as yet, has not garnered broad support. Microsoft, Netscape, and Opera, however, have built-in support for XML and XSLT in the latest versions of their browsers.

Why XSLT is useful
To understand what makes XSLT so useful, let’s look at a simple, browser-based example: Suppose you’ve developed a Web-based time-sheet system that allows users to analyze work hours. If the only tool available is HTML, you will have to develop and provide a set of HTML reports for the user. For each report selected by a user, the browser performs a round-trip to the server. The server process pulls down a data set from a database, formats the HTML, and then sends it on to be transformed into the browser application. In this scenario, while the server does most of the work, there’s also a greater server demand and network resources, which means a higher cost.

If you have clients that can process XSLT stylesheets, however, you would be able to take advantage of the client’s capabilities—in essence, you could design the system differently with the help of XML and XSLT. In this scenario, when a user hits the reports page, a large subset of the time-entry data would appear in an XML file. As the user requests a different report, it would download an XSLT stylesheet that could be dynamically applied to the XML document (which would be cached in the browser) to generate a new report.

Each subsequent request for that report would then use the cached XSLT stylesheet, minimizing future requirements for server round-trips. If the user needs a different set of data (e.g., the last three months of time-sheet data rather than the last two weeks), the browser can request the data from the server, which then returns a new XML document. The browser could also use the same XSLT stylesheets to render different views of the same report (e.g., by date, by customer, by project, with subtotals and totals).

In fact, using Internet Explorer, the user could go offline after downloading XML documents and XSLT stylesheets and continue to analyze the data without an active Internet connection.

A workaround to no XSLT support
If your company or your customers use down-level browsers that don’t support local XSLT processing, you can design your system to keep processing for those clients at the server. But rather than doing it the old way (building HTML by hand), you can apply the XSLT stylesheet to a server-side XML document and send just the resulting HTML back to the client.

The real power here comes from tying a different XSLT stylesheet to each type of browser that requests the report. For example, if an HTML 3.2-capable browser requests a time-sheet report, you can render the HTML so that a standard browser will consume it. But if someone accesses your server using a cellular phone and a WAP browser, you could use a different XSLT stylesheet to provide a WAP document that the browser can consume.

By using XML documents and XSLT stylesheets as the standard rendering methodology at the server, you can easily support any device that needs to connect to your Web server, including not only cellular phones but also handheld devices and set-top boxes.

Using XSLT to enable document exchange
Keep in mind that the uses of XSLT extend beyond its capability to enable Web servers to deliver pages to a broad range of clients. XSLT is the foundation of many of the new enterprise application integration and B2B messaging engine products.

Let’s look at a simple example: Suppose you need to deliver shipping information to customers, but each requires a different document format—some can consume XML documents (in their own format), while others still require flat files.

Rather than hard coding an inventory management system to create a different file for each customer, you would simply need the system to generate an XML file in a standard format that you can manipulate. After producing XML files for each customer in this standard format, you could apply, via programming, an XSLT stylesheet to each customer’s XML document.

The resulting customer documents could be simple transformations (i.e., renaming entities or attributes, shaping the XML differently, etc.) or something as generic as a flat file laid out to a customer's specification.

Technology application is endless
Over the last six months, I’ve taught hundreds of developers about new technologies like XML and XSLT, and I’m constantly amazed at the creative ways they find to apply the technology once they’re given the education.

If your development shop isn’t taking advantage of new technologies like XSLT, then it’s time to take a look, as these are mature technologies with a wide array of tools available on almost any platform.

Editorial standards