Table of Contents
Introduction.
Chapter 1: XSLT in Context.
Chapter 2: The XSLT Processing Model.
Chapter 3: Stylesheet Structure.
Chapter 4: XSLT Elements.
Chapter 5: Expressions.
Chapter 6: Patterns.
Chapter 7: Functions.
Chapter 8: Writing Extension Functions.
Chapter 9: Stylesheet Design Patterns.
Chapter 10: Worked Examples.
Appendix A: Microsoft MSXML3.
Appendix B: Oracle.
Appendix C: Saxon.
Appendix D: Xalan.
Appendix E: Other Products.
Appendix F: TrAX: The Transformation API for XML.
Glossary.
Index A – Elements.
Index B – Functions.
Index C – General.
Read an Excerpt
1: XSLT in Context
This chapter is designed to put XSLT in context. It's about the purpose of XSLT and the
task it was designed to perform. It's about what kind of language it is, and how it came
to be that way; and it's about how XSLT fits in with all the other technologies that you
are likely to use in a typical web-based application. I won't be saying much in this
chapter about what an XSLT stylesheet actually looks like or how it works: that will
come later, in Chapters 2 and 3.
I shall begin by describing the task that XSLT is designed to perform – transformation –
and why there is the need to transform XML documents. I'll then present a trivial
example of a transformation in order to explain what this means in practice.
The chapter then moves on to discuss the relationship of XSLT to other standards in
the growing XML family, to put its function into context and explain how it
complements the other standards.
I'll describe what kind of language XSLT is, and delve a little into the history of how it
came to be like that. If you're impatient you may want to skip the history and get on
with using the language, but sooner or later you will ask "why on earth did they
design it like that?" and at that stage I hope you will go back and read about the
process by which XSLT came into being.
Finally, I'll have a few things to say about the different ways of using XSLT within the
overall architecture of an application, in which there will inevitably be many other
technologies and components each playing their own part.
What is XSLT?
XSLT, which stands for
eXtensible Stylesheet Language: Transformations, is a language
which, according to the very first sentence in the specification (found at
http://www.w3.org/TR/xslt), is primarily designed for transforming one XML document
into another. However, XSLT is more than capable of transforming XML to HTML and
many other text-based formats, so a more general definition might be as follows:
XSLT is a language for transforming the structure of an XML
document.
Why should you want to do that? In order to answer this question properly, we first
need to remind ourselves why XML has proved such a success and generated so much
excitement.
Why Transform XML?
XML is a simple, standard way to interchange structured textual data between
computer programs. Part of its success comes because it is also readable and writable
by humans, using nothing more complicated than a text editor, but this doesn't alter
the fact that it is primarily intended for communication between software systems. As
such, XML satisfies two compelling requirements:
- Separating data from presentation. The need to separate information (such as a
weather forecast) from details of the way it is to be presented on a particular
device. This need is becoming ever more urgent as the range of internet-capable
devices grows. Organizations that have invested in creating valuable
information sources need to be able to deliver them not only to the traditional
PC-based web browser (which itself now comes in many flavors), but also to
TV sets and WAP phones, not to mention the continuing need to produce
print-on-paper.
- Transmitting data between applications. The need to transmit information (such
as orders and invoices) from one organization to another without investing in
bespoke software integration projects. As electronic commerce gathers pace,
the amount of data exchanged between enterprises increases daily and this
need becomes ever more urgent.
Of course, these two ways of using XML are not mutually exclusive. An invoice can be
presented on the screen as well as being input to a financial application package, and
weather forecasts can be summarized, indexed, and aggregated by the recipient
instead of being displayed directly. Another of the key benefits of XML is that it unifies
the worlds of documents and data, providing a single way of representing structure
regardless of whether the information is intended for human or machine consumption.
The main point is that, whether the XML data is ultimately used by people or by a
software application, it will very rarely be used directly in the form it arrives: it first
has to be transformed into something else.
In order to communicate with a human reader, this something else might be a
document that can be displayed or printed: for example an HTML file, a PDF file, or
even audible sound. Converting XML to HTML for display is probably the most
common application of XSLT today, and it is the one I will use in most of the examples
in this book. Once you have the data in HTML format, it can be displayed on any
browser.
In order to transfer data between different applications we need to be able to transform
data from the data model used by one application to the model used in another. To
load the data into an application, the required format might be a comma-separated-values
file, a SQL script, an HTTP message, or a sequence of calls on a particular
programming interface. Alternatively, it might be another XML file using a different
vocabulary from the original. As XML-based electronic commerce becomes
widespread, so the role of XSLT in data conversion between applications also becomes
ever more important. Just because everyone is using XML does not mean the need for
data conversion will disappear. There will always be multiple standards in use. For
example, the newspaper industry is likely to use different formats for exchanging news
articles from the format used in the broadcasting industry. Equally, there will always
be a need to do things like extracting an address from a purchase order and adding it
to an invoice. So linking up enterprises to do e-commerce will increasingly become a
case of defining how to extract and combine data from one set of XML documents to
generate another set of XML documents: and XSLT is the ideal tool for the job.
At the end of this chapter we will come back to specific examples of when XSLT
should be used to transform XML. For now, I just wanted to establish a feel for the
importance and usefulness of transforming XML. Before we move on to discuss XSLT
in more detail and have a first look at how it works, let's take a look at an example that
clearly demonstrates the variety of formats to which we can transform XML, using
XSLT.
An Example: Transforming Music
There is an excellent registry of XML vocabularies and schemas at
http://www.xml.org/xmlorg_registry/index.shtml.
If you look there, you will find half a dozen different XML schemas for describing
music. These were all invented with different purposes in mind: a markup language
used by a publisher for printing sheet music has different requirements from one
designed to let you listen to the music from a browser. MusicML, for example, is
oriented to displaying music notation graphically; ChordML is designed for encoding
the harmonic accompaniment to vocal lyrics; MusicXML is designed to represent
musical scores, specifically western musical notation from the 17th century onwards,
while the rather more academic Music Markup Language (MML) from the University
of Pretoria is designed for serious musicological analysis, embracing Eastern and
African as well as Western musical idioms....
...So you could use XSLT to process marked-up music in many different ways:
- You could use XSLT to convert music from one of these representations to
another, for example from MusicXML to MML.
- You could use XSLT to convert music from any of these representations into
visual music notation, by generating the XML-based vector graphics format
SVG.
- You could use XSLT to play the music on a synthesizer, by generating a MIDI
(Musical Instrument Digital Interface) file.
- You could use XSLT to perform a musical transformation, such as transposing
the music into a different key.
- You could use XSLT to extract the lyrics, into HTML or into a text-only XML
document.
As you can see, XSLT is not just for converting XML documents to HTML!
How does XSLT transform XML?
By now you are probably wondering exactly how XSLT goes about processing an XML
document in order to convert it into the required output. There are usually two aspects
to this process:
- The first stage is a structural transformation, in which the data is converted
from the structure of the incoming XML document to a structure that reflects
the desired output.
- The second stage is formatting, in which the new structure is output in the
required format such as HTML or PDF.
The second stage covers the ground we discussed in the previous section; the data
structure that results from the first stage can be output as HTML, a text file or as XML.
HTML output allows the information to be viewed directly in a browser by a human
user or be input into any modern word processor. Plain text output allows data to be
formatted in the way an existing application can accept, for example comma-separated
values or one of the many text-based data interchange formats that were developed
before XML arrived on the scene. Finally, XML output allows the data to be supplied
to one of the new breed of applications that accepts XML directly. Typically this will
use a different vocabulary of XML tags from the original document: for example an
XSLT transformation might take the monthly sales figures as its XML input and
produce a histogram as its XML output, using the XML-based SVG standard for vector
graphics. Or you could use an XSLT transformation to generate VoxML output, for
aural rendition of your data.
Links to information about Motorola's VoxML Voice Markup Language can
be found at http://www.oasis-open.org/cover/voxML.html
Let's now delve into the first stage, transformation – the stage with which
XSLT is primarily concerned and which makes it possible to provide output in all of
these formats. This stage might involve selecting data, aggregating and grouping it,
sorting it, or performing arithmetic conversions such as changing centimeters to
inches.
So how does this come about? Before the advent of XSLT, you could only process
incoming XML documents by writing a custom application. The application wouldn't
actually need to parse the raw XML, but it would need to invoke an XML parser, via a
defined Application Programming Interface (API), to get information from the
document and do something with it. There are two principal APIs for achieving this:
the Simple API for XML (SAX) and the Document Object Model (DOM).
The SAX API is an event-based interface in which the parser notifies the application of
each piece of information in the document as it is read. If you use the DOM API, then
the parser interrogates the document and builds a tree-like object structure in memory.
You would then write a custom application (in a procedural language such as C++,
Visual Basic, or Java, for example), which could interrogate this tree structure. It would
do so by defining a specific sequence of steps to be followed in order to produce the
required output. Thus, whatever parser you use, this process has the same principal
drawback: every time you want to handle a new kind of XML document, you have to
write a new custom program, describing a different sequence of steps, to process the
XML.
Both the DOM and the SAX APIs are fully described in the Wrox Press book
Professional XML, ISBN 1-861003-11-0.
So how is using XSLT to perform transformations on XML better than writing "custom
applications"? Well, the design of XSLT is based on a recognition that these programs
are all very similar, and it should therefore be possible to describe what they do using
a high-level declarative language rather than writing each program from scratch in
C++, Visual Basic, or Java. The required transformation can be expressed as a set of
rules. These rules are based on defining what output should be generated when
particular patterns occur in the input. The language is declarative, in the sense that you
describe the transformation you require, rather than providing a sequence of
procedural instructions to achieve it. XSLT describes the required transformation and
then relies on the XSLT processor to decide the most efficient way to go about it.
XSLT still relies on an XML parser – be it a DOM parser or a SAX-compliant one – to
convert the XML document into a tree structure. It is the structure of this tree
representation of the document that XSLT manipulates, not the document itself. If you
are familiar with the DOM, then you will be happy with the idea of treating every item
in an XML document (elements, attributes, processing instructions etc.) as a node in a
tree. With XSLT we have a high-level language that can navigate around a node tree,
select specific nodes and perform complex manipulations on these nodes.
The XSLT tree model is similar in concept to the DOM but it is not the same.
The full XSLT processing model is discussed in Chapter 2.
The description of XSLT given thus far (a declarative language that can navigate to and
select specific data and then manipulate that data) may strike you as being similar to
that of the standard database query language, SQL. Let's take a closer look at this
comparison....
loading...