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

The

declaration indicates how the result tree should be serialized. Although the stylesheet is designed to generate XHTML, it uses the XML output method because the XHTML method was introduced only in XSLT 2.0. The main difference is that XHTML serialization is more careful to avoid XML constructs that older HTML browsers might not handle correctly; for example, an empty paragraph represented as

indent=“no”

!indent=yes

This is a useful catchall template rule to make sure that the source document and the stylesheet are consistent with each other. In principle, validating the source document against a DTD should ensure that it contains no surprises. But in practice, DTDs change over time, and there's no way to be sure which version of the DTD was used—indeed, there's no way to be sure that the document was validated at all. So this template rule matches any element for which there is no other more specific template rule in the stylesheet. It produces a message (typically on the console) to indicate that an unexpected element was encountered, and it then copies the offending data to the result document in such a way that the start and end tags will show up visibly in the HTML (in red). This is a good way of helping document authors to notice and correct the error.

The

element is deprecated in XHTML 1.0. Perhaps the stylesheet author used it deliberately so that it would not only show up visually but would also be flagged by an XHTML validator, thus forcing the document author to fix the problem before publication.

I don't know why the stylesheet author felt uneasy about including the code to generate the

element in this template rule. Perhaps it was because the template rule for a document node is invoked when processing the root of any document tree, not only the principal source document. If the logic for creating the skeleton of the output HTML goes in the template rule for the outermost element (which in this case is called

), then it's less likely to be invoked by accident when temporary trees or secondary input documents are processed.

The

in this rule is an example of a common technique, using the stylesheet to detect validity problems in the source document that cannot be enforced by a schema or DTD. I don't think there's any harm in using XSLT to do such validation, but my inclination would be to put it in a separate processing stage from the HTML formatting. It's best to write XML applications as a pipeline in which individual steps perform separate functions. (With XML Schema 1.1, it should become possible to enforce contraints like this one as assertions in the schema.)

The remaining rules in the stylesheet are presented in alphabetical order, by element. This is a good way of making sure that any rule can be found quickly. Unfortunately, it also has a drawback, which is that rules that work closely together (for example, the rules for formatting the front matter, or the rules for outputting syntax productions) can be widely separated in the source file. For the purposes of exposition, I've therefore regrouped them according to their logical function. The first group I will consider are the template rules that handle the general outline of the HTML output.

Creating the HTML Outline

The main template rule is evaluated when the

element in the source document is encountered. This is always the outermost element of the XML document. It's fairly lengthy, so we'll take it piece by piece.

The code starts by generating the

element, giving it a
lang
attribute if and only if the source document defines its language in the form

. This is useful because W3C specifications are often translated into languages other than English. Documenting which language is used can help search engines and browsers designed to make web pages more accessible; for example, with audio rendition. Exceptionally, I have shown the XHTML namespace declaration on this occasion; it actually appears on the outermost literal result element in every template rule.

The next stage is to output the

element. Most of the above section is concerned with generating the document title (as it appears in the title bar of the browser window). This is a concatenation of the