The Place of XSLT in the XML Family

XSLT is published by the World Wide Web Consortium (W3C) and fits into the XML family of standards, most of which are also developed by W3C. In this section I will try to explain the sometimes-confusing relationship of XSLT to other related standards and specifications.

XSLT and XSL

XSLT started life as part of a bigger language called XSL ( Extensible Stylesheet Language ). As the name implies, XSL was (and is) intended to define the formatting and presentation of XML documents for display on screen, on paper, or in the spoken word. As the development of XSL proceeded, it became clear that this was usually a two-stage process: first a structural transformation, in which elements are selected, grouped and reordered; and then a formatting process in which the resulting elements are rendered as ink on paper, or pixels on the screen. It was recognized that these two stages were quite independent, so XSL was split into two parts : XSLT for defining transformations; and "the rest"-which is still officially called XSL, though most people prefer to call it XSL-FO ( XSL Formatting Objects )-for the formatting stage.

XSL-FO is nothing more than another XML vocabulary, in which the objects described are areas of the printed page and their properties. Since this is just another XML vocabulary, XSLT needs no special capabilities to generate this as its output. XSL-FO is outside the scope of this book. It's a big subject (the specification is longer than XSLT). What's more, you're probably less likely to need it than to need XSLT. XSL-FO provides wonderful facilities to achieve high-quality typographical output of your documents. However, for many people translating documents into HTML for presentation by a standard browser is quite good enough, and that can be achieved using XSLT alone, or if necessary, by using XSLT in conjunction with Cascading Stylesheets (CSS or CSS2), which I shall return to shortly.

The XSL-FO specification became a Recommendation on 15 October 2001. It can be found at http://www.w3.org/TR/xsl .

XSLT and XPath

Halfway through the development of XSLT 1.0, it was recognized that there was a significant overlap between the expression syntax in XSLT for selecting parts of a document and the XPointer language being developed for linking from one document to another. To avoid having two separate but overlapping expression languages, the two committees decided to join forces and define a single language, XPath, which would serve both purposes. XPath 1.0 was published on the same day as XSLT 1.0, 16 November 1999.

XPath acts as a sublanguage within an XSLT stylesheet. An XPath expression may be used for numerical calculations or string manipulations, or for testing Boolean conditions, but its most characteristic use (and the one that gives it its name) is to identify parts of the input document to be processed . For example, the following instruction outputs the average price of all the books in the input document:

  <xsl:value-of select="avg(//book/@price)"/>  

Here, the <xsl:value-of> element is an instruction defined in the XSLT standard, which causes a value to be written to the output document. The select attribute contains an XPath expression, which calculates the value to be written: specifically , the average value of the price attributes on all the <book> elements. (The avg() function too is new in XPath 2.0.)

Following its publication, the XPath specification increasingly took on a life of its own, separate from XSLT. Several DOM implementations (including Microsoft's) allowed you to select nodes within a DOM tree structure, using a method such as selectNodes(XPath) , and this feature is now included in the current version of the standard, DOM3. A subset of XPath is used within the XML Schema language, and bindings of XPath to other languages such as Perl are multiplying. The language has also proved interesting to academics , and a number of papers have been published analyzing its semantics, which provides the basis for optimized implementations.

The separation of XPath from XSLT works reasonably well, but as the earlier example shows, you need to understand the interaction between the two languages to see how a stylesheet works. In previous editions of this book I covered both languages together, but this time I have given each language its own volume, mainly because the amount of material had become too large for one book, and also because there are an increasing number of people who use XPath without also using XSLT. For the XSLT user , though, I'm afraid that at times you may have to keep both books open on your desk at once.

XSLT and XML

XSLT is essentially a tool for transforming XML documents. At the start of this chapter we discussed the reasons why this is important, but now we need to look a little more precisely at the relationship between the two. There are two particular aspects of XML that XSLT interacts with very closely: one is XML Namespaces; the other is the XML Information Set. These are discussed in the following sections.

XML Namespaces

XSLT is designed on the basis that XML namespaces are an essential part of the XML standard. So when the XSLT standard refers to an XML document, it really means an XML document that also conforms to the XML Namespaces specification, which can be found at http://www.w3.org/TR/REC-xml- names .

For a full explanation of XML Namespaces, see Chapter 11 of XML 1.1 Bible, Third Edition (Wiley, 2004).

Namespaces play an important role in XSLT. Their purpose is to allow you to mix tags from two different vocabularies in the same XML document. For example, in one vocabulary <table> might mean a two-dimensional array of data values, while in another vocabulary <table> refers to a piece of furniture. Here's a quick reminder of how they work:

• Namespaces are identified by a Uniform Resource Identifier (URI). This can take a number of forms. One form is the familiar URL, for example http://www.wrox.com/namespace . Another form, not fully standardized but being used in some XML vocabularies, is a URN, for example urn:biztalk-org:biztalk:biztalk_1" . The detailed form of the URI doesn't matter, but it is a good idea to choose one that will be unique. One good way of achieving this is to use the URL of your own Web site. But don't let this confuse you into thinking that there must be something on the Web site for the URL to point to. The namespace URI is simply a string that you have chosen to be different from other people's namespace URIs; it doesn't need to point to anything.

• The latest version, XML Namespaces 1.1, allows you to use an International Resource Identifier (IRI) rather than a URI. The main difference is that this permits characters from any alphabet; it is no longer confined to ASCII. In practice, most XML parsers have always allowed you to use any characters you like in a namespace URI.

• Since namespace URIs are often rather long and use special characters such as «/ » , they are not used in full as part of the element and attribute names. Instead, each namespace used in a document can be given a short nickname, and this nickname is used as a prefix of the element and attribute names. It doesn't matter what prefix you choose, because the real name of the element or attribute is determined only by its namespace URI and its local name (the part of the name after the prefix). For example, all my examples use the prefix xsl to refer to the namespace URI http://www.w3.org/1999/XSL/ Transform , but you could equally well use the prefix xslt , so long as you use it consistently.

• For element names, you can also declare a default namespace URI, which is to be associated with unprefixed element names. The default namespace URI, however, does not apply to unprefixed attribute names.

A namespace prefix is declared using a special pseudo-attribute within any element start tag, with the form:

  xmlns:    prefix    = "    namespace-URI    "  

This declares a namespace prefix, which can be used for the name of that element, for its attributes, and for any element or attribute name contained in that element. The default namespace, which is used for elements having no prefix (but not for attributes), is similarly declared using a pseudo-attribute:

  xmlns = "    namespace-URI    "  

XSLT can't be used to process an XML document unless it conforms to the XML Namespaces Recommendation. In practice this isn't a problem, because most people are treating XML Namespaces as an intrinsic part of the XML standard, rather than a bolt-on optional extra. It does have certain implications, though. In particular, serious use of Namespaces is difficult to combine with serious use of Document Type Definitions (DTDs), because DTDs don't recognize the special significance of prefixes in element names; so, a consequence of backing Namespaces is that XSLT provides very little support for DTDs, having chosen instead to wait for the replacement facility, XML Schemas.

XM+L Namespaces 1.1 became a Recommendation on 4 February 2004, and the XSLT 2.0 specification makes provision for XSLT processors to work with this version, though it isn't required. Apart from the largely cosmetic change from URIs to IRIs mentioned earlier, the main innovation is the ability to undeclare a namespace, using a namespace undeclaration of the form «xmlns:prefix="" » . This is particularly intended for applications like SOAP messaging, where an XML payload document is wrapped in an XML envelope for transmission. Without namespace undeclarations, there is a tendency for namespaces used in the SOAP envelope to stick to the payload XML when this is removed from the envelope, which can cause validation failures and other problems. For example, it can invalidate a digital signature attached to the document.

The XML Information Set

XSLT is designed to work on the information carried by an XML document, not on the raw document itself. This means that, as an XSLT programmer, you are given a tree view of the source document. This tree view is an abstraction of the original lexical XML, in which information that's deemed significant is retained, and other information is discarded. For example, you can see the attribute names and values, but you can't see whether the attribute was written in single or double quotes, you can't see what order the attributes were in, and you can't tell whether or not they were written on the same line.

One messy detail is that there have been many attempts to define exactly what constitutes the essential information content of a well- formed XML document, as distinct from its accidental punctuation. All attempts so far have come up with slightly different answers. The most definitive attempt to provide a common vocabulary for the content of XML documents is the XML Information Set definition (usually called the InfoSet), which may be found at http://www.w3.org/TR/xml-infoset .

Unfortunately, the InfoSet came too late to make all the standards consistent. For example, some treat comments as significant, others not; some treat the choice of namespace prefixes as significant, others take them as irrelevant. In Chapter 2, I shall describe exactly how XSLT (or more accurately, XPath) defines the tree model of XML, and how it differs in finer points of detail from some of the other definitions such as the Document Object Model or DOM.

One new piece of jargon is the concept of the post schema validation infoset or PSVI. This contains the significant information from the source document, augmented with information taken from its XML schema. It therefore allows you to find out not only that the value of an attribute was «17.3 » , but also that the attribute was described in the schema as a non-negative decimal number. A major change in XSLT 2.0 is that if you choose to use a schema processor to validate your documents, your XSLT stylesheets now make use of this additional information in the PSVI.

XSL and CSS

Why are there two stylesheet languages, XSL (that is, XSLT plus XSL Formatting Objects) as well as Cascading Style Sheets (CSS and CSS2)?

It's only fair to say that in an ideal world there would be a single language in this role, and that the reason there are two is that no one was able to invent something that achieved the simplicity and economy of CSS for doing simple things, combined with the power of XSL for doing more complex things.

CSS (by which I include CSS2, which greatly extends the degree to which you can control the final appearance of the page) is mainly used for rendering HTML, but it can also be used for rendering XML directly, by defining the display characteristics of each XML element. However, it has serious limitations. It cannot reorder the elements in the source document, it cannot add text or images, it cannot decide which elements should be displayed and which omitted, neither can it calculate totals or averages or sequence numbers . In other words, it can only be used when the structure of the source document is already very close to the final display form.

Having said this, CSS is simple to write, and it is very economical in machine resources. It doesn't reorder the document, and so it doesn't need to build a tree representation of the document in memory, and it can start displaying the document as soon as the first text is received over the network. Perhaps, most important of all, CSS is very simple for HTML authors to write, without any programming skills. In comparison, XSLT is far more powerful, but it also consumes a lot more memory and processor power, as well as training budget.

It's often appropriate to use both tools together. Use XSLT to create a representation of the document that is close to its final form, in that it contains the right text in the right order, and then use CSS to add the finishing touches, by selecting font sizes, colors, and so on. Typically, you would do the XSLT processing on the server and the CSS processing on the client (in the browser); so, another advantage of this approach is that you reduce the amount of data sent down the line, which should improve response time for your users and postpone the next expensive bandwidth increase.

XSLT and XML Schemas

One of the biggest changes in XSLT 2.0, and one of the most controversial , is the integration of XSLT with the XML Schema language. XML Schema provides a replacement for DTDs as a way of specifying the structural constraints that apply to a class of documents; unlike DTDs, an XML Schema can regulate the content of the text as well as the nesting of the elements and attributes. Many of the industry vocabularies being used to define XML interchange standards are specified using XML Schema definitions. For example, several of the XML vocabularies for describing music, which I alluded to earlier in the chapter, have an XML Schema to define their rules, and this schema can be used to check the conformance of individual documents to the standard in question.

When you write a stylesheet, you need to make assumptions about the structure of the input documents it is designed to process and the structure of the result documents it is designed to produce. With XSLT 1.0, these assumptions were implicit; there was no formal way of stating the assumptions in the stylesheet itself. As a result, if you try applying a stylesheet to the wrong kind of input document, the result will generally be garbage.

The idea of linking XSLT and XML Schema was driven by two main considerations:

• There should, in principle, be software engineering benefits if a program (and a stylesheet is indeed a program) makes explicit assertions about its expected inputs and outputs. These assertions can lead to better and faster detection of errors, often enabling errors to be reported at compile time that otherwise would only be reported the first time the stylesheet was applied to some test data that happened to exercise a particular part of the code.

• The more information that's available to an XSLT processor at compile time, the more potential it has to generate optimal code, giving faster execution and better use of memory.

So why the controversy? It's mainly because XML Schema itself is less than universally popular. It's an extremely complex specification that's very hard to read, and when you discover what it says, it appears to be full of rules that seem artificial and inconsistent. It manages at the same time to be specified in very formal language, and yet to have a worryingly high number of bugs that have been fixed through published errata. Although there are good books that present XML Schema in a more readable way, they achieve this by glossing over the complications, which means that the error messages you get when you do something wrong can be extremely obscure. As a result, there has been a significant amount of support for an alternative schema language, Relax NG, which as it happens was co-developed by the designer of XSLT and XPath, James Clark, and is widely regarded as a much more elegant approach.

The XSL and XQuery working groups responded to these concerns by ensuring that support for XML Schema was optional, both for implementors and for users. However, this has not entirely quelled the voices of dissent. Some have asked for XSLT to offer a choice of schema languages. However, this is technically very difficult to achieve, since the structure of data and the semantics of the operations that can be performed on the data are so closely coupled with each other.

The signs are that XML Schema is here to stay, whether people like it or not. It has the backing of all the major software vendors such as IBM, Oracle, and Microsoft, and it is being adopted by many of the larger user organizations and industries. And like so many things that the IT world has adopted as standards, it may be imperfect but it does actually work. Meanwhile, to simplify the situation rather cruelly, Relax NG is taking the role of the Apple Macintosh: the choice of the cognoscenti who judge a design by its intrinsic quality rather than by its list of heavyweight backers.

As I've already mentioned, W3C is not an organization that likes to let a thousand flowers bloom. It is not a loose umbrella organization in which each working group is free to do its own thing. There are strong processes that ensure the working groups cooperate and strive to reconcile their differences. There is therefore a determination to make all the specifications work properly together, and the message is that if XML Schema has its problems, then you work together to get them fixed. XSLT and XML Schema come from the same stable, so they are expected to work together. And I hope to show in this book that they can work together beneficially.

Chapter 4 provides an overview of how stylesheets and schemas are integrated in XSLT 2.0, and Chapter 11 provides a worked example of an application that uses this capability. In developing this application for the book (which I did at the same time as I developed the underlying support in Saxon) I was pleasantly surprised to see that I really was getting benefits from the integration. At the simplest level, I really liked the immediate feedback you get when a stylesheet generates output that does not conform to the schema for the result document, with error messages that point straight to the offending line in the stylesheet. This makes for a much faster debugging cycle than does the old approach of putting the finished output file through a schema validator as a completely separate operation.