XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition (699 page)

Note that the

element (which is of course a synonym for

) specifies
version=“1.0”
. This doesn't guarantee that the stylesheet makes no use of XSLT 2.0 features, but it's a good clue: it means that when the stylesheet is run on an XSLT 2.0 processor, it will run in backward-compatibility mode, and when run on an XSLT 1.0 processor, errors will be reported at compile time if any XSLT 2.0 constructs are found. This stylesheet is widely used to produce a whole range of documents, and like most other organizations, W3C wouldn't want its business-critical publishing operation to rely on software that isn't yet widely implemented. So the main stylesheet does indeed stick to XSLT 1.0. As we'll see later, some of the “overlays” to the stylesheet do take advantage of 2.0.

The reference to the Saxon namespace (in fact the old Saxon 6.5 namespace) in the header turns out to be a red herring. There is no use of this namespace within the body of the document, and the stylesheet has no dependencies on features specific to Saxon or any other XSLT processor. Someone put this in to do some experiments and forgot to take it out. It does no harm, apart from raising a false alarm about the portability of the stylesheet.

A fairly standard control header. There's then some legal stuff, without which we would not be able to reproduce the code in this book. There's a lot of change history as well, which I'll leave out.

These two elements together indicate that boundary whitespace (whitespace that appears in whitespace-only text nodes) is to be retained for all elements except the long list of elements whose whitespace is to be stripped. The

element here is actually redundant, because the default is to preserve whitespace anyway. The elements listed for stripping are essentially those that do not allow mixed content in the DTD. It would be nice if there were an easier way of achieving this, but sadly there isn't, not even in XSLT 2.0.

Some processors, notably those from Microsoft and Altova, strip whitespace text nodes unconditionally before XSLT processing starts. This stripping can cause problems when the source document contains nodes in which whitespace is significant. You can see the consequence of this in
Figure 18-3
, which shows an extract from section 1.2 of the XML Recommendation, as rendered in Internet Explorer.

Figure 18-3

Note the absence of any space between the hyperlinked phrase “XML processor” and the word “MUST”. In the XML source, the relevant markup is:

Between the

element and the

element there is whitespace (lots of it), which should be displayed in HTML as a single space; but the Microsoft XML parser has stripped the space, so the words run together on the screen. The only real way to avoid this, when transformations are invoked using the

processing instruction, is to add an
xml:space=“preserve”
attribute to some containing element in the XML source.

Let's move on. The next thing in the stylesheet is a set of parameter declarations:

These global parameters allow the behavior of the stylesheet to be customized. Like many publishing organizations, W3C tries hard to maintain a consistent house style for its publications, and the use of a common DTD and stylesheet goes a long way toward achieving this. However, different publications do have different requirements, so there is a need to manage variety. Sometimes, the authors needed to introduce a new feature in the stylesheet but didn't want to change the way existing documents were rendered, so they put in a parameter to control the new feature. Sometimes, the parameters reflect the needs of different stages in the publication cycle; for example, the parameter
show.ednotes
controls whether editorial notes should be displayed.