/packages/tex/info/examples/lwc/ch7/xsl.xml on ftp.icm.edu.pl

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="stylesheet/xml.dsl" type="text/dsssl"?>
Default handler: 
<spec>
 <header>
 <title>
 Extensible Stylesheet Language (XSL)
 </title>
 <version>
 Version 1.0
 </version>
 <w3c-designation>
 WD-xsl-
Default handler: &year;
Default handler: &MMDD;
 </w3c-designation>
 <w3c-doctype>
 World Wide Web Consortium Working Draft
 </w3c-doctype>
 <pubdate>
 <dayDefault handler: &day;
/>
 <monthDefault handler: &month;
/>
 <yearDefault handler: &year;
/>
 </pubdate>
 <publoc>
 <loc href="http://www.w3.org/TR/1998/WD-xsl-19981202">
 http://www.w3.org/TR/
Default handler: &year;
 /WD-xsl-
Default handler: &year;
Default handler: &MMDD;
 </loc>
 <loc href="http://www.w3.org/TR/1998/WD-xsl-19981202.xml">
 http://www.w3.org/TR/
Default handler: &year;
 /WD-xsl-
Default handler: &year;
Default handler: &MMDD;
 .xml
 </loc>
 <loc href="http://www.w3.org/TR/1998/WD-xsl-19981202.html">
 http://www.w3.org/TR/
Default handler: &year;
 /WD-xsl-
Default handler: &year;
Default handler: &MMDD;
 .html
 </loc>
 <loc href="http://www.w3.org/TR/1998/WD-xsl-19981202.pdf">
 http://www.w3.org/TR/
Default handler: &year;
 /WD-xsl-
Default handler: &year;
Default handler: &MMDD;
 .pdf
 </loc>
 </publoc>
 <latestloc>
 <loc href="http://www.w3.org/TR/WD-xsl">
 http://www.w3.org/TR/WD-xsl
 </loc>
 </latestloc>
 <prevlocs>
 <loc href="http://www.w3.org/TR/1998/WD-xsl-19980818">
 http://www.w3.org/TR/1998/WD-xsl-19980818
 </loc>
 </prevlocs>
 <authlist>
 <author part="Tree Construction">
 <name>
 James Clark
 </name>
 <email href="mailto:[email protected]">
 [email protected]
 </email>
 </author>
 <author part="Formatting Objects">
 <name>
 Stephen Deach
 </name>
 <affiliation>
 Adobe
 </affiliation>
 <email href="mailto:[email protected]">
 [email protected]
 </email>
 </author>
 </authlist>
 <status>
 
 This is a W3C Working Draft for review by W3C members and other
 interested parties. This adds additional functionality to what was
 described in the the previous draft, however the basic of the previous
 draft remains unchanged. It is a draft document and may be updated,
 replaced, or obsoleted by other documents at any time. The XSL
 Working Group will not allow early implementation to constrain its
 ability to make changes to this specification prior to final release.
 It is inappropriate to use W3C Working Drafts as reference material or
 to cite them as other than
 <quote>
 work in progress
 </quote>
 . A list of
 current W3C working drafts can be found at
 <loc href="http://www.w3.org/TR">
 http://www.w3.org/TR
 </loc>
 .
 
 
 Comments may be sent to
 <loc href="mailto:[email protected]">
 [email protected]
 </loc>
 . Public
 discussion of XSL takes place on the
 <loc href="http://www.mulberrytech.com/xsl/xsl-list/index.html">
 XSL-List
 </loc>
 mailing list.
 
 </status>
 <abstract>
 
 XSL is a language for expressing stylesheets. It consists of two
 parts:
 
 <olist>
 <item>
 
 a language for transforming XML documents, and
 
 </item>
 <item>
 
 an XML vocabulary for specifying formatting
 semantics.
 
 </item>
 </olist>
 
 An XSL stylesheet specifies the presentation of a class of XML
 documents by describing how an instance of the class is transformed
 into an XML document that uses the formatting vocabulary.
 
 </abstract>
 <langusage>
 <language id="EN">
 English
 </language>
 <language id="ebnf">
 EBNF
 </language>
 </langusage>
 <revisiondesc>
 <slist>
 <sitem>
 See RCS log for revision history.
 </sitem>
 </slist>
 </revisiondesc>
 </header>
 <body>
 <div1>
 <head>
 Overview
 </head>
 
 XSL is a language for expressing stylesheets. Each stylesheet
 describes rules for presenting a class of XML source documents. There
 are two parts to the presentation process. First, the result tree is
 constructed from the source tree. Second, the result tree is
 interpreted to produce formatted output on a display, on paper, in
 speech or onto other media.
 
 
 The first part, constructing the result tree, is achieved by
 associating patterns with templates. A pattern is matched against
 elements in the source tree. A template is instantiated to create
 part of the result tree. The result tree is separate from the source
 tree. The structure of the result tree can be completely different
 from the structure of the source tree. In constructing the result
 tree, the source tree can be filtered and reordered, and arbitrary
 structure can be added.
 
 
 The second part, formatting, is achieved by using the formatting
 vocabulary specified in this document to construct the result tree.
 Formally, this vocabulary is an XML namespace. Each element type in the
 vocabulary corresponds to a formatting object class. A formatting
 object class represents a particular kind of formatting behavior. For
 example, the block formatting object class represents the breaking of
 the content of a paragraph into lines. Each attribute in the
 vocabulary corresponds to a formatting property. A formatting object
 class has a specific set of formatting properties which provide finer
 control over the behavior of the formatting object class; for example,
 controlling indenting of lines, spacing between lines, and spacing
 before and after the collection of lines. A formatting object can
 have content, and its formatting behavior is applied to its
 content.
 
 
 XSL does not require result trees to use the formatting vocabulary
 and thus can be used for general XML transformations. For example,
 XSL can be used to transform XML to
 <quote>
 well-formed
 </quote>
 HTML,
 that is, XML that uses the element types and attributes defined by
 HTML.
 
 
 When the result tree uses the formatting vocabulary, a conforming
 XSL implementation must be able to interpret the result tree according
 to the semantics of the formatting vocabulary as defined in this
 document; it may also be able to externalize the result tree as XML,
 but it is not required to be able to do so.
 
 
 This document does not specify how a stylesheet is associated with
 an XML document. It is recommended that XSL processors support the
 mechanism described in
 <bibref ref="XMLSTYLE"/>
 .
 
 </div1>
 <div1>
 <head>
 Tree Construction
 </head>
 <div2>
 <head>
 Overview
 </head>
 
 A stylesheet contains a set of template rules. A
 template rule has two parts: a pattern which is matched against nodes
 in the source tree and a template which can be instantiated
 to form part of the result tree. This allows a stylesheet to be applicable to
 a wide class of documents that have similar source tree
 structures.
 
 
 A template is instantiated for a particular source element
 to create part of the result tree. A template can contain elements
 that specify literal result element structure. A template can also
 contain elements that are instructions for creating result tree
 fragments. When a template is instantiated, each instruction is
 executed and replaced by the result tree fragment that it creates.
 Instructions can select and process descendant elements. Processing a
 descendant element creates a result tree fragment by finding the
 applicable template rule and instantiating its template. Note
 that elements are only processed when they have been selected by the
 execution of an instruction. The result tree is constructed by
 finding the template rule for the root node and instantiating
 its template.
 
 
 In the process of finding the applicable template rule, more
 than one template rule may have a pattern that matches a given
 element. However, only one template rule will be applied. The
 method for deciding which template rule to apply is described
 in
 <specref ref="conflict"/>
 .
 
 
 XSL uses XML namespaces
 <bibref ref="XMLNAMES"/>
 to distinguish
 elements that are instructions to the XSL processor from elements that
 specify literal result tree structure. Instruction elements all
 belong to the XSL namespace. The examples in this document use a
 prefix of
 <code>
 xsl:
 </code>
 for elements in the XSL namespace.
 
 
 An XSL stylesheet contains an
 <code>
 xsl:stylesheet
 </code>
 document
 element. This element may contain
 <code>
 xsl:template
 </code>
 elements
 specifying template rules, which will be described later in
 this document.
 
 
 The following is an example of a simple XSL stylesheet that
 constructs a result tree for a sequence of
 <code>
 para
 </code>
 elements.
 The
 <code>
 result-ns="fo"
 </code>
 attribute indicates that a tree using
 the formatting object vocabulary is being constructed. The rule for
 the root node specifies the use of a page sequence formatted with any
 font with serifs. The
 <code>
 para
 </code>
 elements become
 <code>
 block
 </code>
 formatting objects which are set in 10 point type
 with a 12 point space before each block.
 
 <eg>
 <xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl" xmlns:fo="http://www.w3.org/TR/WD-xsl/FO" result-ns="fo"> <xsl:template match="/"> <fo:page-sequence font-family="serif"> <xsl:apply-templates/> </fo:page-sequence> </xsl:template> <xsl:template match="para"> <fo:block font-size="10pt" space-before="12pt"> <xsl:apply-templates/> </fo:block> </xsl:template> </xsl:stylesheet>
 </eg>
 
 The
 <code>
 xsl:stylesheet
 </code>
 element can also contain elements
 importing other XSL stylesheets, elements defining macros, elements
 defining global constants, and elements identifying source attributes
 as individual element identifiers.
 
 </div2>
 <div2>
 <head>
 Stylesheet Structure
 </head>
 
 A stylesheet is represented by an
 <code>
 xsl:stylesheet
 </code>
 element in an XML document.
 
 
 XSL processors must use the XML namespaces mechanism
 <bibref ref="XMLNAMES"/>
 for both source documents and stylesheets. All XSL
 defined elements, that is those specified in this document with a
 prefix of
 <code>
 xsl:
 </code>
 , will only be recognized by the XSL
 processor if they belong to a namespace with the URI
 <code>
 http://www.w3.org/TR/WD-xsl
 </code>
 ; XSL defined elements are
 recognized only in the stylesheet not in the source document.
 
 <issue id="issue-versioning">
 
 Should there be some way for a
 stylesheet to indicate which version of XSL it conforms to? Can this
 be done through the URI of the XSL namespace?
 
 </issue>
 
 The
 <code>
 xsl:stylesheet
 </code>
 element has an optional
 <code>
 result-ns
 </code>
 attribute; the value must be a namespace
 prefix. If this attribute is specified, all result elements must
 belong to the namespace identified by this prefix (the
 <term>
 result
 namespace
 </term>
 ). If there is a namespace declared as the default
 namespace, then an empty string may be used as the value to specify
 that the default namespace is the result namespace. If the
 <code>
 result-ns
 </code>
 attribute specifies the XSL Formatting Objects
 namespace, then in addition to constructing the result XML tree, the
 XSL processor must interpret it according to the semantics defined in
 this document. The XSL Formatting Objects namespace has the URI
 <code>
 http://www.w3.org/TR/WD-xsl/FO
 </code>
 . The examples in this
 document use the
 <code>
 fo:
 </code>
 prefix for this namespace.
 
 <note>
 
 If an implementation wishes to use something in the result
 tree or stylesheet to control the output of a non-XML representation
 of the result tree, it should use the result namespace. In
 particular, if it wishes to make use of something in the result tree
 or stylesheet to indicate that the result tree should be output as
 HTML that conforms to the HTML 4.0 Recommendation rather than as XML,
 it should use a result namespace of
 <code>
 http://www.w3.org/TR/REC-html40
 </code>
 ; for example,
 
 <eg>
 <xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl" xmlns="http://www.w3.org/TR/REC-html40" result-ns=""> <xsl:template match="/"> <html> <xsl:apply-templates/> </html> </xsl:template> ... </xsl:stylesheet>
 </eg>
 </note>
 
 The
 <code>
 xsl:stylesheet
 </code>
 element may contain the following types
 of elements:
 
 <olist>
 <item>
 
 <code>
 xsl:import
 </code>
 
 </item>
 <item>
 
 <code>
 xsl:include
 </code>
 
 </item>
 <item>
 
 <code>
 xsl:id
 </code>
 
 </item>
 <item>
 
 <code>
 xsl:strip-space
 </code>
 
 </item>
 <item>
 
 <code>
 xsl:preserve-space
 </code>
 
 </item>
 <item>
 
 <code>
 xsl:macro
 </code>
 
 </item>
 <item>
 
 <code>
 xsl:attribute-set
 </code>
 
 </item>
 <item>
 
 <code>
 xsl:constant
 </code>
 
 </item>
 <item>
 
 <code>
 xsl:template
 </code>
 
 </item>
 </olist>
 
 This example shows the structure of a stylesheet. Ellipses
 (
 <code>
 ...
 </code>
 ) indicate where attribute values or content have
 been omitted.
 Although this example shows one of each type of allowed element,
 stylesheets may contain zero or more of each of these elements.
 
 <eg>
 <?xml version="1.0"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl"> <xsl:import href="..."/> <xsl:include href="..."/> <xsl:id attribute="..."/> <xsl:strip-space element="..."/> <xsl:preserve-space element="..."/> <xsl:macro name="..."> ... </xsl:macro> <xsl:attribute-set name="..."> ... </xsl:attribute-set> <xsl:constant name="..." value="..."/> <xsl:template match="..."> ... </xsl:template> </xsl:stylesheet>
 </eg>
 
 The order in which the children of the
 <code>
 xsl:stylesheet
 </code>
 element occur is not significant except for
 <code>
 xsl:import
 </code>
 elements and for error recovery. Users are free to order the elements
 as they prefer, and stylesheet creation tools need not provide control
 over the order in which the elements occur.
 
 <issue id="issue-media-rule">
 
 Should we provide the functionality
 of CSS's
 <code>
 @media
 </code>
 rule and if so how?
 
 </issue>
 </div2>
 <div2>
 <head>
 Processing Model
 </head>
 <ednote>
 <edtext>
 This needs expanding and polishing.
 </edtext>
 </ednote>
 
 A node is processed to create a result tree fragment. The
 result tree is constructed by processing the root node. A node is
 processed by finding all the template rules with patterns that
 match the node, and choosing the best amongst them. The chosen rule's
 template is then instantiated for the node.
 <termdef id="dt-current-node" term="Current Node">
 During the instantiation of
 a template, the node for which the template is being
 instantiated is called the current node.
 </termdef>
 A template
 typically contains instructions that select an additional sequence of
 source nodes for processing. A sequence of source nodes is processed
 by appending the result tree structure created by processing each of
 the members of the sequence in order. The process of matching,
 instantiation and selection is continued recursively until no new
 source nodes are selected for processing.
 
 
 Implementations are free to process the source document in any way
 that produces the same result as if it were processed using this
 processing model.
 
 </div2>
 <div2 id="data-model">
 <head>
 Data Model
 </head>
 
 XSL operates on an XML document, whether a stylesheet or a source
 document, as a tree. Any two stylesheets or source documents that
 have the same tree will be processed the same by XSL. The XML
 document resulting from the tree construction process is also a tree.
 This section describes how XSL models an XML document as a tree. This
 model is conceptual only and does not mandate any particular
 implementation.
 
 
 XML documents operated on by XSL must conform to the XML namespaces
 specification
 <bibref ref="XMLNAMES"/>
 .
 
 
 The tree contains nodes. There are seven kinds of node:
 
 <ulist>
 <item>
 
 root nodes
 
 </item>
 <item>
 
 element nodes
 
 </item>
 <item>
 
 text nodes
 
 </item>
 <item>
 
 attribute nodes
 
 </item>
 <item>
 
 namespace nodes
 
 </item>
 <item>
 
 processing instruction nodes
 
 </item>
 <item>
 
 comment nodes
 
 </item>
 </ulist>
 
 Neither processing instruction nodes nor comment nodes are included
 in the tree for the stylesheet.
 
 
 For every type of node there is a way of determing a string
 <term>
 value
 </term>
 for a node of that type. For some types of node,
 the value is part of the node; for other types of node, the value is
 computed from the value of descendant nodes.
 
 <issue id="issue-data-entity">
 
 Should XSL provide support for
 external data entities and notations?
 
 </issue>
 <div3 id="root-node">
 <head>
 Root Node
 </head>
 
 The root node is the root of the tree. It does not occur anywhere
 else in the tree. It has a single child which is the element node for
 the document element of the document.
 
 
 The
 <term>
 value
 </term>
 of the root node is the value of the
 document element.
 
 </div3>
 <div3 id="element-nodes">
 <head>
 Element Nodes
 </head>
 
 There is an element node for every element in the document. An
 element has an expanded name consisting of a local name and a possibly
 null URI (see
 <bibref ref="XMLNAMES"/>
 ); the URI will be null if the
 element type name has no prefix and there is no default namespace in
 scope.
 
 
 The children of an element node are the element nodes and
 characters for its content. Entity references to both internal and
 external entities are expanded. Character references are
 resolved.
 
 
 <termdef id="dt-descendants" term="Descendants">
 The
 <term>
 descendants
 </term>
 of an element node are the character
 children, the element node children, and the descendants of the
 element node children.
 </termdef>
 
 
 The
 <term>
 value
 </term>
 of an element node is the string that
 results from concatenating all characters that are
 <termref def="dt-descendants">
 descendants
 </termref>
 of the element node in the
 order in which they occur in the document.
 
 
 <termdef id="dt-document-order" term="Document Order">
 The set of
 all element nodes in a document can be ordered according to the order
 of the start-tags of the elements in the document; this is known as
 <term>
 document order
 </term>
 .
 </termdef>
 
 <div4 id="unique-id">
 <head>
 Unique IDs
 </head>
 
 An element object may have a unique identifier (ID). This is the
 value of the attribute which is declared in the DTD as type
 <code>
 ID
 </code>
 . Since XSL must also work with XML documents that do
 not have a DTD, stylesheets may specify which attributes in the source
 document should be treated as IDs. The
 <code>
 xsl:id
 </code>
 element
 has a required
 <code>
 attribute
 </code>
 attribute, which gives the name
 of an attribute in the source document that should be treated as
 specifying the element's ID. A stylesheet may contain more than one
 <code>
 xsl:id
 </code>
 element, for cases where the source document uses
 several attributes as IDs. An
 <code>
 xsl:id
 </code>
 element also has an
 optional
 <code>
 element
 </code>
 attribute which specifies the name of an
 element type; when the
 <code>
 element
 </code>
 attribute is specified,
 then the
 <code>
 xsl:id
 </code>
 element specifies that the
 <code>
 attribute
 </code>
 attribute of
 <code>
 element
 </code>
 elements are
 treated as IDs.
 <code>
 xsl:id
 </code>
 elements may only occur in the
 stylesheet body (not within a rule). The following causes XSL to
 treat all
 <code>
 name
 </code>
 attributes in the source document as
 IDs.
 
 <eg>
 <xsl:id attribute="name"/>
 </eg>
 
 It is an error if, as a consequence of the use of
 <code>
 xsl:id
 </code>
 , there is more than one element with the same ID
 in the source tree. An XSL processor may signal the error; if it does
 not signal the error, it must recover by treating only the first (in
 <termref def="dt-document-order">
 document order
 </termref>
 ) of the
 elements as having that ID.
 
 <issue id="unique-id-content">
 
 Should it be possible for a unique id
 to be specified in the content of an element instead of in an
 attribute?
 
 </issue>
 </div4>
 <div4 id="base-uri">
 <head>
 Base URI
 </head>
 
 An element node also has an associated URI called its base URI
 which is used for resolving attribute values that represent relative
 URIs into absolute URIs. If an element occurs in an external entity,
 the base URI of that element is the URI of the external entity.
 Otherwise the base URI is the base URI of the document.
 
 </div4>
 </div3>
 <div3 id="attribute-nodes">
 <head>
 Attribute Nodes
 </head>
 
 Each element node has an associated set of attribute nodes. A
 defaulted attribute is treated the same as a specified attribute. If
 an attribute was declared for the element type, but the default was
 declared as
 <code>
 #IMPLIED
 </code>
 , and the attribute was not specified
 on the element, then the element's attribute set does not contain a
 node for the attribute.
 
 
 An attribute node has an expanded name and has a string value. The
 expanded name consists of a local name and a possibly null URI (see
 <bibref ref="XMLNAMES"/>
 ); the URI will be null if the specified
 attribute name did not have a prefix. The value is the normalized
 value as specified by the XML Recommendation
 <bibref ref="XML"/>
 . An
 attribute value whose value is of zero length is not treated
 specially.
 
 
 There are no attribute nodes for attributes that declare namespaces
 (see
 <bibref ref="XMLNAMES"/>
 ).
 
 <issue id="issue-external-dtd">
 
 Should we specify something about
 how we expect XSL processors to process external DTDs and parameter
 entities? For example, what happens if an attribute default is
 declared in an external DTD?
 
 </issue>
 </div3>
 <div3 id="namespace-nodes">
 <head>
 Namespace Nodes
 </head>
 
 Each element has an associated set of namespace nodes, one for each
 namespace prefix that is in scope for element and one for the default
 namespace if one is in scope for the element. This means that an
 element will have a namespace node:
 
 <ulist>
 <item>
 
 for every attribute on the element whose name starts with
 <code>
 xmlns:
 </code>
 ;
 
 </item>
 <item>
 
 for every attribute on an ancestor element whose name starts
 <code>
 xmlns:
 </code>
 unless the element itself or a nearer ancestor
 redeclares the prefix;
 
 </item>
 <item>
 
 for an
 <code>
 xmlns
 </code>
 attribute, unless its value is the empty
 string.
 
 <note>
 
 An attribute
 <code>
 xmlns=""
 </code>
 <quote>
 undeclares
 </quote>
 the default namespace (see
 <bibref ref="XMLNAMES"/>
 ).
 
 </note>
 </item>
 </ulist>
 
 A namespace node has a name which is a string giving the prefix.
 This is empty if the namespace node is for the default namespace. A
 namespace node also has a value which is the namespace URI. If the
 namespace declaration specifies a relative URI, then the resolved
 absolute URI is used as the value.
 
 
 When writing an element node in the result tree out as XML, an XSL
 processor must add sufficient namespace-declaring attributes to the
 start-tag to ensure that if a tree were recreated from the XML, then
 the set of namespace nodes on the element node in the recreated tree
 would be equal to or a superset of the set of namespace nodes of the
 element node in the result tree.
 
 <note>
 
 The semantics of a document type may treat parts of attribute
 values or data content as namespace prefixes. The presence of
 namespace nodes ensures that the semantics can be preserved when the
 tree is written out as XML.
 
 </note>
 </div3>
 <div3>
 <head>
 Processing Instruction Nodes
 </head>
 
 There is a processing instruction node for every processing
 instruction.
 
 <ednote>
 <edtext>
 What about processing instructions in the internal
 subset or elsewhere in the DTD?
 </edtext>
 </ednote>
 
 An processing instruction has a name. This is a string equal to
 the processing instruction's target. It also has a value. This is a
 string equal to the part of the processing instruction following the
 target and any whitespace. It does not include the terminating
 <code>
 ?
 >
 </code>
 .
 
 </div3>
 <div3>
 <head>
 Comment Nodes
 </head>
 
 There is a comment node for every comment.
 
 <ednote>
 <edtext>
 What about comments in the internal subset or
 elsewhere in the DTD?
 </edtext>
 </ednote>
 
 A comment has a value. This is a string equal to the text of the
 comment not including the opening
 <code>
 <
 !--
 </code>
 or the closing
 <code>
 --
 >
 </code>
 .
 
 </div3>
 <div3>
 <head>
 Text Nodes
 </head>
 
 Character data is grouped into text nodes. As much character data
 as possible is grouped into each text node: a text node never has an
 immediately following or preceding sibling that is a text node. The
 value of a text node is the character data.
 
 
 Each character within
 a CDATA section is treated as character data. Thus
 <code>
 <
 ![CDATA[
 <
 ]]
 >
 </code>
 in the source document will
 treated the same as
 <code>
 &
 lt;
 </code>
 . Characters inside comments
 or processing instructions are not character data. Line-endings in
 external entities are normalized to #xA as specified in the XML
 Recommendation
 <bibref ref="XML"/>
 .
 
 </div3>
 <div3 id="strip">
 <head>
 Whitespace Stripping
 </head>
 
 After the tree has been constructed, but before it is otherwise
 processed by XSL, some text nodes may be stripped. The
 stripping process takes as input a set of element types for which
 whitespace must be preserved. The stripping process is applied to
 both stylesheets and source documents, but the set of
 whitespace-preserving element types is determined differently for
 stylesheets and for source documents.
 
 
 A text node is preserved if any of the following apply:
 
 <ulist>
 <item>
 
 The element type of the parent of the text node is in the set
 of whitespace-preserving element types.
 
 </item>
 <item>
 
 The text node contains at least one non-whitespace character.
 As in XML, a whitespace character is #x20, #x9, #xD or #xA.
 
 </item>
 <item>
 
 An ancestor element of the text node has an
 <code>
 xml:space
 </code>
 attribute with a value of
 <code>
 preserve
 </code>
 , and no closer ancestor element has
 <code>
 xml:space
 </code>
 with a value of
 <code>
 default
 </code>
 .
 
 </item>
 </ulist>
 
 Otherwise the text node is stripped.
 
 
 The
 <code>
 xml:space
 </code>
 attributes are not stripped from the
 tree.
 
 <note>
 
 This implies that if an
 <code>
 xml:space
 </code>
 attribute is
 specified on a literal result element, it will be included in the
 result.
 
 </note>
 
 For stylesheets, the set of whitespace-preserving element types
 consists of just
 <code>
 xsl:text
 </code>
Default handler: 
 .
 
Default handler: 
 
 For source documents, the set of whitespace-preserving element
 types is determined using the stylesheet as follows:
 
 <ulist>
 <item>
 
 If the
 <code>
 xsl:stylesheet
 </code>
 element specifies a
 <code>
 default-space
 </code>
 attribute with a value of
 <code>
 strip
 </code>
 , then the set is initially empty. Otherwise the
 set initially contains all element types that occur in the
 document.
 
 </item>
 <item>
 
 The
 <code>
 xsl:strip-space
 </code>
 element causes an element
 type to be removed from the set of whitespace-preserving element types.
 The
 <code>
 element
 </code>
 attribute gives the name of the element
 type.
 
 </item>
 <item>
 
 The
 <code>
 xsl:preserve-space
 </code>
 element causes an element
 type to be added to the set whitespace-preserving element types. The
 <code>
 element
 </code>
 attribute gives the name of the element
 type.
 
 </item>
 </ulist>
 <issue id="issue-declare-multiple-elements">
 
 Should the value of the
 <code>
 element
 </code>
 attribute of
 <code>
 xsl:strip-space
 </code>
 ,
 <code>
 xsl:preserve-space
 </code>
 and
 <code>
 xsl:id
 </code>
 be a list of
 element type names (and thus be renamed to
 <code>
 elements
 </code>
 )? If
 so, should the
 <code>
 attribute
 </code>
 attribute of
 <code>
 xsl:id
 </code>
 also be a list of attribute names?
 
 </issue>
 <ednote>
 <edtext>
 Clarify how these declarations interact with each
 other and with xsl:import.
 </edtext>
 </ednote>
 
 The
 <code>
 xsl:stylesheet
 </code>
 element can include an
 <code>
 indent-result
 </code>
 attribute with values
 <code>
 yes
 </code>
 or
 <code>
 no
 </code>
 . If the stylesheet specifies
 <code>
 indent-result="yes"
 </code>
 , then the XSL processor may add
 whitespace to the result tree (possibly based on whitespace stripped
 from either the source document or the stylesheet) in order to indent
 the result nicely; if
 <code>
 indent-result="no"
 </code>
 , it must not add
 any whitespace to the result. When adding whitespace with
 <code>
 indent-result="yes"
 </code>
 , the XSL processor can use any
 algorithm provided that the result is the same as the result with
 <code>
 indent-result="no"
 </code>
 after whitespace is stripped from both
 using the process described with the set of whitespace-preserving
 element types consisting of just
 <code>
 xsl:text
 </code>
Default handler: 
 .
 
 </div3>
 </div2>
 <div2>
 <head>
 Template Rules
 </head>
 
 A template rule is specified with the
 <code>
 xsl:template
 </code>
 element. The
 <code>
 match
 </code>
 attribute identifies the source node
 or nodes to which the rule applies. The content of the
 <code>
 xsl:template
 </code>
 element is the template.
 
 
 For example, an XML document might contain:
 
 <eg>
 This is an <emph>important</emph> point.
 </eg>
 
 The following template rule matches elements of type
 <code>
 emph
 </code>
 and has a template which produces a
 <code>
 fo:sequence
 </code>
 formatting object with a
 <code>
 font-weight
 </code>
 property of
 <code>
 bold
 </code>
 .
 
 <eg>
 <xsl:template match="emph"> <fo:sequence font-weight="bold"> <xsl:apply-templates/> </fo:sequence> </xsl:template>
 </eg>
 
 As described later, the
 <code>
 xsl:apply-templates
 </code>
 element
 recursively processes the children of the source element.
 
 <div3 id="conflict">
 <head>
 Conflict Resolution for Template Rules
 </head>
 
 It is possible for a source node to match more than one
 template rule. The template rule to be used is determined as
 follows:
 
 <olist>
 <item>
 
 First, all matching template rules that are less
 <termref def="dt-important">
 important
 </termref>
 than the most
 important matching template rule or rules are eliminated from
 consideration.
 
 </item>
 <item>
 
 Next, all matching template rules that have a lower priority
 than the matching template rule or rules with the highest priority are
 eliminated from consideration. The priority of a rule is specified by
 the
 <code>
 priority
 </code>
 attribute on the rule. The value of this
 must be a real number (positive or negative). The default priority is
 0.
 
 <ednote>
 <edtext>
 Say exactly what syntax is allowed for real
 numbers.
 </edtext>
 </ednote>
 </item>
 </olist>
 
 It is an error if this leaves more than one matching template
 rule. An XSL processor may signal the error; if it does not signal
 the error, it must recover by choosing from amongst the matching
 template rules that are left the one that occurs last in the
 stylesheet.
 
 </div3>
 <div3>
 <head>
 Built-in Template Rule
 </head>
 
 There is a built-in template rule to allow recursive
 processing to continue in the absence of a successful pattern match by
 an explicit rule in the stylesheet. This rule applies to both element
 nodes and the root node. The following shows the equivalent of the
 built-in template rule:
 
 <eg>
 <xsl:template match="*|/"> <xsl:apply-templates/> </xsl:template>
 </eg>
 
 The built-in template rule is treated as if it were imported
 implicitly before the stylesheet and so is considered less
 <termref def="dt-important">
 important
 </termref>
 than all other template
 rules. Thus the author can override the built-in rule by including an
 explicit rule with
 <code>
 match="*|/"
 </code>
 .
 
 
 There is also a built-in template rule for text nodes
 that copies text through:
 
 <eg>
 <xsl:template match="text()"> <xsl:value-of select="."/> </xsl:template>
 </eg>
 
 The built-in rule does not apply to processing instructions and
 comments. When a comment or processing instruction is processed, and
 no rule is matched, nothing is created.
 
 </div3>
 </div2>
 <div2>
 <head>
 Patterns
 </head>
 <div3>
 <head>
 Introduction
 </head>
 
 This section introduces the syntax and semantics of XSL patterns.
 The formal, definitive specification is in the following section.
 
 
 A pattern is a string which selects a set nodes in a source
 document. The selection is relative to the current node. The
 simplest pattern is an element type name; it selects all the child
 elements of the current node with that element type name. For
 example, the pattern
 <code>
 chapter
 </code>
 selects all the chapter
 child elements of the current node.
 
 
 A pattern can also be matched against a node. If a node could be
 selected by a pattern, then the node is considered to match the
 pattern. More precisely, for any pattern and any document there is a
 matching set of nodes; this is the union, for each node in the
 document, of the set of nodes selected by the pattern with that node
 as the current node. For example, a pattern
 <code>
 chapter
 </code>
 matches any chapter element because if the current node was the parent
 of the chapter element, the chapter element would be one of the nodes
 selected by the pattern
 <code>
 chapter
 </code>
 . This includes the case
 where the
 <code>
 chapter
 </code>
 element is the document element,
 because the root node is the parent of the document element.
 
 
 The
 <code>
 |
 </code>
 operator can be used to express alternatives.
 For example, the pattern
 <code>
 emph|b
 </code>
 matches both
 <code>
 emph
 </code>
 elements and
 <code>
 b
 </code>
 elements.
 
 
 Patterns can be composed together with the
 <code>
 /
 </code>
 operator
 in a path-like manner. For example, a pattern
 <code>
 chapter/section
 </code>
 selects the
 <code>
 chapter
 </code>
 child
 elements of the current node, and then for each selected
 <code>
 chapter
 </code>
 element, selects the
 <code>
 section
 </code>
 children; in other words, it selects the
 <code>
 section
 </code>
 grandchildren of the current node that have
 <code>
 chapter
 </code>
 parents. A node would match a pattern
 <code>
 chapter/section
 </code>
 if
 it was a
 <code>
 section
 </code>
 element with a
 <code>
 chapter
 </code>
 parent.
 
 
 <code>
 /
 </code>
 binds more tightly than
 <code>
 |
 </code>
 . Thus the
 pattern
 <code>
 ol/li|ul/li
 </code>
 matches
 <code>
 li
 </code>
 elements that
 have a
 <code>
 ol
 </code>
 or
 <code>
 ul
 </code>
 parent.
 
 
 Whitespace can be used around operators in patterns to improve
 readability. Thus
 <code>
 ol/li|ul/li
 </code>
 can be written as
 <code>
 ol/li | ul/li
 </code>
 .
 
 
 <code>
 *
 </code>
 can be used instead of an element type name as a
 wildcard. For example, a pattern
 <code>
 *
 </code>
 would select all
 element children of the current node; a pattern
 <code>
 */section
 </code>
 would select all
 <code>
 section
 </code>
 grandchildren of the current
 node. A pattern
 <code>
 chapter/*
 </code>
 would match any element that
 has a
 <code>
 chapter
 </code>
 parent.
 
 
 A
 <code>
 //
 </code>
 can be used instead of
 <code>
 /
 </code>
 to select
 from descendants instead of from children. For example, a pattern
 <code>
 chapter//p
 </code>
 selects all the
 <code>
 p
 </code>
 descendants of
 <code>
 chapter
 </code>
 children of the current node, and it matches all
 <code>
 p
 </code>
 elements that have a
 <code>
 chapter
 </code>
 ancestor.
 
 
 A pattern
 <code>
 .
 </code>
 selects the current node. This is useful
 with
 <code>
 //
 </code>
 . For example,
 <code>
 .//div
 </code>
 selects all
 <code>
 div
 </code>
 descendant elements of the current node.
 
 
 Similarily
 <code>
 ..
 </code>
 selects the parent of the current node.
 For example,
 <code>
 ../item
 </code>
 selects the
 <code>
 item
 </code>
 sibling elements of the current node.
 
 
 Other types of node are treated in a similar way to elements.
 
 <ulist>
 <item>
 
 The attributes of an element are treated like the child
 elements; an attribute is distinguished from a child element by
 prefixing its name with
 <code>
 @
 </code>
 . For example,
 <code>
 @date
 </code>
 will select the
 <code>
 date
 </code>
 attribute of the
 current element;
 <code>
 employee/@salary
 </code>
 will select the
 <code>
 salary
 </code>
 attribute of each
 <code>
 employee
 </code>
 child
 element of the current node. A wildcard
 <code>
 @*
 </code>
 is allowed
 just as with elements; a pattern
 <code>
 @*
 </code>
 selects all
 attributes of the current node.
 
 </item>
 <item>
 
 A pattern
 <code>
 comment()
 </code>
 selects all comment children
 of the current node. Thus a pattern
 <code>
 comment()
 </code>
 will match
 any comment node.
 
 </item>
 <item>
 
 A pattern
 <code>
 pi()
 </code>
 selects all processing
 instruction children of the current node. An argument can be used to
 specify the target. Thus
 <code>
 pi("xml-stylesheet")
 </code>
 matches
 any processing instruction with a target
 <code>
 xml-stylesheet
 </code>
 .
 Note that the argument must be quoted.
 
 </item>
 </ulist>
 
 The set of nodes selected by a pattern can be refined by following
 the pattern by a test in square brackets (
 <code>
 []
 </code>
 ). Each node
 in the set is tested. The result includes only those nodes for which
 test succeeds. The following are allowed as tests:
 
 <ulist>
 <item>
 
 A pattern can be used a test; the test succeeds if the
 pattern selects one or more nodes when the node being tested is the
 current node. For example, a pattern
 <code>
 list[@type]
 </code>
 matches
 a
 <code>
 list
 </code>
 element with a
 <code>
 type
 </code>
 attribute; a
 pattern
 <code>
 book[editor]
 </code>
 selects
 <code>
 book
 </code>
 children
 elements of the current node that have at least one
 <code>
 editor
 </code>
 child element.
 
 </item>
 <item>
 
 A pattern can be compared to string. For example, a pattern
 <code>
 list[@type="ordered"]
 </code>
 would match any list with an
 attribute
 <code>
 type
 </code>
 with value
 <code>
 ordered
 </code>
 ; a pattern
 <code>
 employee[location="USA"]
 </code>
 would select
 <code>
 employee
 </code>
 children of the current element that have a
 <code>
 location
 </code>
 child with content equal to
 <code>
 USA
 </code>
 .
 
 </item>
 <item>
 
 The position of a node relative to its siblings can be
 tested.
 
 <ulist>
 <item>
 
 <code>
 first-of-any()
 </code>
 succeeds if the node being tested
 is the first element child
 
 </item>
 <item>
 
 <code>
 last-of-any()
 </code>
 succeeds if the node being tested
 is the last element child
 
 </item>
 <item>
 
 <code>
 first-of-type()
 </code>
 succeeds if the node being
 tested is the first element child of its element type
 
 </item>
 <item>
 
 <code>
 last-of-type()
 </code>
 succeeds if the node being
 tested is the first element child of its element type
 
 </item>
 </ulist>
 </item>
 <item>
 
 A test can be negated using
 <code>
 not()
 </code>
 . For example,
 <code>
 list[not(@type)]
 </code>
 matches any
 <code>
 list
 </code>
 element
 without a
 <code>
 type
 </code>
 attribute.
 
 </item>
 <item>
 
 Tests can be combined with
 <code>
 and
 </code>
 and
 <code>
 or
 </code>
 . For example,
 
 <eg>
 back/div[first-of-type() and last-of-type()]
 </eg>
 
 matches a
 <code>
 div
 </code>
 element with a
 <code>
 back
 </code>
 parent,
 when it is the only
 <code>
 div
 </code>
 child of its parent.
 
 </item>
 </ulist>
 
 The
 <code>
 []
 </code>
 operator binds more tightly than
 <code>
 |
 </code>
 . Thus the pattern
 <code>
 ol|list[@type="ordered"]
 </code>
 matches either
 <code>
 list
 </code>
 elements with a
 <code>
 type
 </code>
 attribute with value
 <code>
 ordered
 </code>
 or
 <code>
 ol
 </code>
 elements.
 
 
 The root node is treated is specially. A
 <code>
 /
 </code>
 at the
 beginning of a pattern selects the root node (not the document
 element). For example, a pattern that is just
 <code>
 /
 </code>
 matches
 the root node; a pattern
 <code>
 /div
 </code>
 will match the document
 element it is a
 <code>
 div
 </code>
 element; a pattern
 <code>
 /*
 </code>
 will match the document element whatever is. When a pattern starts
 with
 <code>
 /
 </code>
 the current node is irrelevant.
 
 
 A pattern can also start with
 <code>
 //
 </code>
 .
 <code>
 //foo
 </code>
 means the same as
 <code>
 /.//foo
 </code>
 : it selects the
 <code>
 foo
 </code>
 descendants of the root node, which implies that it
 selects all foo elements. When a pattern starts with
 <code>
 //
 </code>
 the current node is irrelevant.
 
 
 The
 <code>
 ancestor
 </code>
 function allows selection of an ancestor
 of the current node. The argument is a match pattern. It selects the
 first ancestor of the current node that matches the argument. For
 example,
 <code>
 ancestor(chapter)/title
 </code>
 will select the
 <code>
 title
 </code>
 children of the first ancestor of the current node
 that is a
 <code>
 chapter
 </code>
 .
 
 
 The
 <code>
 id
 </code>
 function allows ID references to be followed.
 The argument can be a literal string. For example,
 <code>
 id('foo')
 </code>
 will select the element with ID
 <code>
 foo
 </code>
 ; if there is no such element, the empty node set will
 be returned. Multiple whitespace separated IDs are also allowed; this
 <code>
 id('foo bar')
 </code>
 would select elements with an ID
 <code>
 foo
 </code>
 or
 <code>
 bar
 </code>
 . The argument can be a pattern
 instead of a literal string; for each node selected by the pattern,
 the value of the node is treated as whitespace separated list of ID
 references. For example, if the current node is an element with an
 IDREF or IDREFS attribute named
 <code>
 ref
 </code>
 , then a pattern
 <code>
 id(@ref)
 </code>
 would select the elements referenced by the
 <code>
 ref
 </code>
 attribute.
 
 <ednote>
 <edtext>
 Would it be less confusing to call this
 idref?
 </edtext>
 </ednote>
 </div3>
 <div3>
 <head>
 Syntax and Semantics
 </head>
 
 An expression is evaluated with respect to a context, which is a
 single node. The result of evaluating an expression is a set of nodes
 or a boolean.
 
 
 In the following grammar, the nonterminal
 <xnt href="http://www.w3.org/TR/WD-xml-names#NT-QName">
 QName
 </xnt>
 is defined in
 <bibref ref="XMLNAMES"/>
 , and
 <xnt href="http://www.w3.org/TR/REC-xml#NT-S">
 S
 </xnt>
 is defined in
 <bibref ref="XML"/>
 .
 
 <scrap>
 <head>
 Selecting
 </head>
 <prod id="NT-SelectExpr">
 <lhs>
 SelectExpr
 </lhs>
 <rhs>
 <nt def="NT-UnionExpr">
 UnionExpr
 </nt>
 </rhs>
 </prod>
 </scrap>
 
 <termdef id="dt-select-pattern" term="Select Pattern">
 A
 <term>
 select pattern
 </term>
 must match the production for
 <nt def="NT-SelectExpr">
 SelectExpr
 </nt>
 ; it returns the list of nodes that
 results from evaluating the
 <nt def="NT-SelectExpr">
 SelectExpr
 </nt>
 with the current node as context; the nodes are in the list are in
 <termref def="dt-document-order">
 document
 order
 </termref>
 .
 </termdef>
 
 <scrap>
 <head>
 Matching
 </head>
 <prod id="NT-MatchExpr">
 <lhs>
 MatchExpr
 </lhs>
 <rhs>
 <nt def="NT-SelectExpr">
 SelectExpr
 </nt>
 </rhs>
 </prod>
 </scrap>
 
 <termdef id="dt-match-pattern" term="Match Pattern">
 A
 <term>
 match
 pattern
 </term>
 must match the production for
 <nt def="NT-MatchExpr">
 MatchExpr
 </nt>
 ; a node matches the match pattern if
 the
 <nt def="NT-MatchExpr">
 MatchExpr
 </nt>
 returns true when evaluated
 with that node as context.
 </termdef>
 
 
 The result of the
 <nt def="NT-MatchExpr">
 MatchExpr
 </nt>
 is true if,
 for any node in the document that contains the context of the
 <nt def="NT-MatchExpr">
 MatchExpr
 </nt>
 , the result of evaluating the
 <nt def="NT-SelectExpr">
 SelectExpr
 </nt>
 with that node as context contains
 the context of the
 <nt def="NT-MatchExpr">
 MatchExpr
 </nt>
 . Otherwise
 the result is false.
 
 
 For implementation reasons, the functionality of
 <nt def="NT-MatchExpr">
 MatchExpr
 </nt>
 s is restricted as follows:
 
 <ulist>
 <item>
 
 Within a
 <nt def="NT-BooleanExpr">
 BooleanExpr
 </nt>
 in a
 <nt def="NT-MatchExpr">
 MatchExpr
 </nt>
 , a
 <nt def="NT-SelectExpr">
 SelectExpr
 </nt>
 must be a
 <nt def="NT-NodeExpr">
 SubNodeExpr
 </nt>
 . More informally, within
 <code>
 []
 </code>
 in a match pattern,
 <code>
 /
 </code>
 ,
 <code>
 //
 </code>
 and
 <code>
 []
 </code>
 must not be used. For example,
 <code>
 foo[bar/baz]
 </code>
 is not allowed as a match
 pattern.
 
 </item>
 <item>
 
 Within a
 <nt def="NT-MatchExpr">
 MatchExpr
 </nt>
 , an
 <nt def="NT-OtherNodeExpr">
 OtherNodeExpr
 </nt>
 must be a
 <nt def="NT-ConstantIdExpr">
 ConstantIdExpr
 </nt>
 .
 
 </item>
 </ulist>
 <scrap>
 <head>
 Unions
 </head>
 <prod id="NT-UnionExpr">
 <lhs>
 UnionExpr
 </lhs>
 <rhs>
 <nt def="NT-PathExpr">
 PathExpr
 </nt>
 </rhs>
 <rhs>
 | (
 <nt def="NT-PathExpr">
 PathExpr
 </nt>
 '|'
 <nt def="NT-UnionExpr">
 UnionExpr
 </nt>
 )
 </rhs>
 </prod>
 </scrap>
 
 The context of the right hand side expressions is the context of
 the left hand side expression. The results of the right hand side
 expressions are node sets. The result of the left hand side
 <nt def="NT-UnionExpr">
 UnionExpr
 </nt>
 is the union of the results of the
 right hand side expressions.
 
 <scrap>
 <head>
 Paths
 </head>
 <prod id="NT-PathExpr">
 <lhs>
 PathExpr
 </lhs>
 <rhs>
 <nt def="NT-AbsolutePathExpr">
 AbsolutePathExpr
 </nt>
 </rhs>
 <rhs>
 |
 <nt def="NT-ComposeExpr">
 ComposeExpr
 </nt>
 </rhs>
 </prod>
 </scrap>
 
 The context of the right hand side expressions is the context of
 the left hand side expression. The result of the left hand side is
 the result of the right hand side. The result is a node set.
 
 <scrap>
 <head>
 Absolute Paths
 </head>
 <prod id="NT-AbsolutePathExpr">
 <lhs>
 AbsolutePathExpr
 </lhs>
 <rhs>
 '/'
 <nt def="NT-SubtreeExpr">
 SubtreeExpr
 </nt>
 ?
 </rhs>
 </prod>
 </scrap>
 
 If the
 <nt def="NT-SubtreeExpr">
 SubtreeExpr
 </nt>
 is present, then
 the context for the
 <nt def="NT-SubtreeExpr">
 SubtreeExpr
 </nt>
 is the
 root node, and the result is the result of the
 <nt def="NT-SubtreeExpr">
 SubtreeExpr
 </nt>
 . Otherwise the result is the
 root node.
 
 <scrap>
 <head>
 Subtrees
 </head>
 <prod id="NT-SubtreeExpr">
 <lhs>
 SubtreeExpr
 </lhs>
 <rhs>
 '/'?
 <nt def="NT-ComposeExpr">
 ComposeExpr
 </nt>
 </rhs>
 </prod>
 </scrap>
 
 If the
 <code>
 /
 </code>
 is present, then the result
 <nt def="NT-SubtreeExpr">
 SubtreeExpr
 </nt>
 is the union, for each node in
 the subtree rooted at the context of the
 <nt def="NT-SubtreeExpr">
 SubtreeExpr
 </nt>
 , of the result of evaluating the
 <nt def="NT-ComposeExpr">
 ComposeExpr
 </nt>
 with that node as context.
 Otherwise the
 <nt def="NT-SubtreeExpr">
 SubtreeExpr
 </nt>
 is equivalent
 to
 <nt def="NT-ComposeExpr">
 ComposeExpr
 </nt>
 .
 
 <scrap>
 <head>
 Composition
 </head>
 <prod id="NT-ComposeExpr">
 <lhs>
 ComposeExpr
 </lhs>
 <rhs>
 <nt def="NT-FilterExpr">
 FilterExpr
 </nt>
 </rhs>
 <rhs>
 | (
 <nt def="NT-FilterExpr">
 FilterExpr
 </nt>
 '/'
 <nt def="NT-SubtreeExpr">
 SubtreeExpr
 </nt>
 )
 </rhs>
 </prod>
 </scrap>
 
 The context of the
 <nt def="NT-FilterExpr">
 FilterExpr
 </nt>
 is the
 context of the
 <nt def="NT-ComposeExpr">
 ComposeExpr
 </nt>
 . If the
 <nt def="NT-SubtreeExpr">
 SubtreeExpr
 </nt>
 is present, then, for each node
 in the result of the
 <nt def="NT-FilterExpr">
 FilterExpr
 </nt>
 , the
 <nt def="NT-SubtreeExpr">
 SubtreeExpr
 </nt>
 is evaluated with that node as
 the context; the result of the
 <nt def="NT-ComposeExpr">
 ComposeExpr
 </nt>
 is the union of the results of evaluating the
 <nt def="NT-SubtreeExpr">
 SubtreeExpr
 </nt>
 . Otherwise the result is the
 result of the
 <nt def="NT-FilterExpr">
 FilterExpr
 </nt>
 .
 
 <scrap>
 <head>
 Filtering
 </head>
 <prod id="NT-FilterExpr">
 <lhs>
 FilterExpr
 </lhs>
 <rhs>
 <nt def="NT-NodeExpr">
 NodeExpr
 </nt>
 ( '['
 <nt def="NT-BooleanExpr">
 BooleanExpr
 </nt>
 ']' )?
 </rhs>
 </prod>
 </scrap>
 
 The context of the
 <nt def="NT-NodeExpr">
 NodeExpr
 </nt>
 is the
 context of the
 <nt def="NT-FilterExpr">
 FilterExpr
 </nt>
 . If the
 <nt def="NT-BooleanExpr">
 BooleanExpr
 </nt>
 is present, then for each node
 in the result of the
 <nt def="NT-NodeExpr">
 NodeExpr
 </nt>
 , the
 <nt def="NT-BooleanExpr">
 BooleanExpr
 </nt>
 is evaluated with that node as
 context; the result consists of those nodes for which the
 <nt def="NT-BooleanExpr">
 BooleanExpr
 </nt>
 evaluates to true.
 
 <scrap>
 <head>
 Selecting Nodes
 </head>
 <prod id="NT-NodeExpr">
 <lhs>
 NodeExpr
 </lhs>
 <rhs>
 <nt def="NT-SubNodeExpr">
 SubNodeExpr
 </nt>
 </rhs>
 <rhs>
 |
 <nt def="NT-OtherNodeExpr">
 OtherNodeExpr
 </nt>
 </rhs>
 </prod>
 <prod id="NT-SubNodeExpr">
 <lhs>
 SubNodeExpr
 </lhs>
 <rhs>
 <nt def="NT-ElementExpr">
 ElementExpr
 </nt>
 </rhs>
 <rhs>
 |
 <nt def="NT-AttributeExpr">
 AttributeExpr
 </nt>
 </rhs>
 <rhs>
 |
 <nt def="NT-TextExpr">
 TextExpr
 </nt>
 </rhs>
 <rhs>
 |
 <nt def="NT-CommentExpr">
 CommentExpr
 </nt>
 </rhs>
 <rhs>
 |
 <nt def="NT-PiExpr">
 PiExpr
 </nt>
 </rhs>
 </prod>
 <prod id="NT-OtherNodeExpr">
 <lhs>
 OtherNodeExpr
 </lhs>
 <rhs>
 <nt def="NT-IdExpr">
 IdExpr
 </nt>
 </rhs>
 <rhs>
 |
 <nt def="NT-AncestorExpr">
 AncestorExpr
 </nt>
 </rhs>
 <rhs>
 |
 <nt def="NT-IdentityExpr">
 IdentityExpr
 </nt>
 </rhs>
 <rhs>
 |
 <nt def="NT-ParentExpr">
 ParentExpr
 </nt>
 </rhs>
 </prod>
 </scrap>
 
 The context of the right hand side expressions is the context of
 the left hand side expression. The results of the right hand side
 expressions are node sets. The result of the left hand side is the
 result of the left hand side expression.
 
 <issue id="issue-multiple-sources">
 
 Should it be possible for
 patterns to select nodes in documents other than the source
 document?
 
 </issue>
 <issue id="issue-sibling-qual">
 
 Should there be qualifiers that
 constrain an element to have an immediately preceding or following
 sibling of a particular type?
 
 </issue>
 <scrap>
 <head>
 Elements
 </head>
 <prod id="NT-ElementExpr">
 <lhs>
 ElementExpr
 </lhs>
 <rhs>
 <xnt href="http://www.w3.org/TR/WD-xml-names#NT-QName">
 QName
 </xnt>
 </rhs>
 <rhs>
 | '*'
 </rhs>
 </prod>
 </scrap>
 
 If
 <code>
 *
 </code>
 is specified, then the result is the child
 elements of the context of the
 <nt def="NT-ElementExpr">
 ElementExpr
 </nt>
 . Otherwise, the result is the
 set of all elements that are the children of the context of
 <nt def="NT-ElementExpr">
 ElementExpr
 </nt>
 and whose name is equal to
 <xnt href="http://www.w3.org/TR/WD-xml-names#NT-QName">
 QName
 </xnt>
 .
 
 
 When comparing the name of an element to a
 <xnt href="http://www.w3.org/TR/WD-xml-names#NT-QName">
 QName
 </xnt>
 , the
 <xnt href="http://www.w3.org/TR/WD-xml-names#NT-QName">
 QName
 </xnt>
 is expanded into a local name
 and a possibly null URI. This expansion is done in the same way as
 for element type names in start and end-tags except that the the
 default namespace declared with
 <code>
 xmlns
 </code>
 is not used: if the
 <xnt href="http://www.w3.org/TR/WD-xml-names#NT-QName">
 QName
 </xnt>
 does not have a prefix,
 then the URI is null (this is the same way attribute names are
 expanded). The expanded element type names are are compared (see
 <specref ref="element-nodes"/>
 ).
 
 <issue id="issue-pattern-namespace-wildcards">
 
 Should patterns of
 the form
 <code>
 foo:*
 </code>
 or
 <code>
 *:foo
 </code>
 be allowed? If so,
 should
 <code>
 *
 </code>
 match any element or any element without a
 namespace URI?
 
 </issue>
 <scrap>
 <head>
 Attributes
 </head>
 <prod id="NT-AttributeExpr">
 <lhs>
 AttributeExpr
 </lhs>
 <rhs>
 ('@'
 <xnt href="http://www.w3.org/TR/WD-xml-names#NT-QName">
 QName
 </xnt>
 )
 </rhs>
 <rhs>
 | ('@' '*')
 </rhs>
 </prod>
 </scrap>
 
 If
 <code>
 *
 </code>
 is specified, the result is the set of attribute
 nodes of the context of the
 <nt def="NT-AttributeExpr">
 AttributeExpr
 </nt>
 . If a
 <xnt href="http://www.w3.org/TR/WD-xml-names#NT-QName">
 QName
 </xnt>
 is specified, the result is the
 attribute node of the context of the
 <nt def="NT-AttributeExpr">
 AttributeExpr
 </nt>
 named
 <xnt href="http://www.w3.org/TR/WD-xml-names#NT-QName">
 QName
 </xnt>
 , or the empty node set if there
 is no such attribute node. When matching attribute names, the
 expanded names are compared (see
 <specref ref="attribute-nodes"/>
 ). The
 <xnt href="http://www.w3.org/TR/WD-xml-names#NT-QName">
 QName
 </xnt>
 is expanded in the same way as
 a
 <xnt href="http://www.w3.org/TR/WD-xml-names#NT-QName">
 QName
 </xnt>
 in an
 <nt def="NT-ElementExpr">
 ElementExpr
 </nt>
 .
 
 <issue id="issue-attribute-qual-case">
 
 Do we need to be able
 to match attributes in a case insensitive way?
 
 </issue>
 <scrap>
 <head>
 Processing Instructions
 </head>
 <prod id="NT-PiExpr">
 <lhs>
 PiExpr
 </lhs>
 <rhs>
 'pi('
 <nt def="NT-Literal">
 Literal
 </nt>
 ? ')'
 </rhs>
 </prod>
 </scrap>
 
 If the
 <nt def="NT-Literal">
 Literal
 </nt>
 is present, the result is
 the set of processing instruction nodes which are children of the
 context of the
 <nt def="NT-PiExpr">
 PiExpr
 </nt>
 and whose target is
 equal to the value of
 <nt def="NT-Literal">
 Literal
 </nt>
 . Otherwise
 the result is the set of processing instruction nodes which are
 children of the context of the
 <nt def="NT-PiExpr">
 PiExpr
 </nt>
 .
 
 <scrap>
 <head>
 Text
 </head>
 <prod id="NT-TextExpr">
 <lhs>
 TextExpr
 </lhs>
 <rhs>
 'text(' ')'
 </rhs>
 </prod>
 </scrap>
 
 The result is the set of all text nodes whose parent is a node in
 the context of the
 <nt def="NT-TextExpr">
 TextExpr
 </nt>
 .
 
 <issue id="issue-regex">
 
 Should XSL support regular
 expressions for matching against any or all of pcdata content,
 attribute values, attribute names, element type names?
 
 </issue>
 <scrap>
 <head>
 Comments
 </head>
 <prod id="NT-CommentExpr">
 <lhs>
 CommentExpr
 </lhs>
 <rhs>
 'comment(' ')'
 </rhs>
 </prod>
 </scrap>
 
 The result is the set of all comment nodes which are children of
 the context of the
 <nt def="NT-CommentExpr">
 CommentExpr
 </nt>
 .
 
 <scrap>
 <head>
 IDs
 </head>
 <prod id="NT-IdExpr">
 <lhs>
 IdExpr
 </lhs>
 <rhs>
 <nt def="NT-ConstantIdExpr">
 ConstantIdExpr
 </nt>
 </rhs>
 <rhs>
 |
 <nt def="NT-VariableIdExpr">
 VariableIdExpr
 </nt>
 </rhs>
 </prod>
 <prod id="NT-ConstantIdExpr">
 <lhs>
 ConstantIdExpr
 </lhs>
 <rhs>
 'id('
 <nt def="NT-Literal">
 Literal
 </nt>
 ')'
 </rhs>
 </prod>
 <prod id="NT-VariableIdExpr">
 <lhs>
 VariableIdExpr
 </lhs>
 <rhs>
 'id('
 <nt def="NT-SelectExpr">
 SelectExpr
 </nt>
 ')'
 </rhs>
 </prod>
 </scrap>
 
 The context of the
 <nt def="NT-SelectExpr">
 SelectExpr
 </nt>
 is the
 context of the
 <nt def="NT-IdExpr">
 IdExpr
 </nt>
 . A set of names is
 computed from the argument as follows:
 
 <ulist>
 <item>
 
 If it is a
 <nt def="NT-ConstantIdExpr">
 ConstantIdExpr
 </nt>
 , then
 the value of the
 <nt def="NT-Literal">
 Literal
 </nt>
 is treated as a
 whitespace-separated list of names; the set of names are the members
 of the list.
 
 </item>
 <item>
 
 Otherwise, the value of each node in the result of the
 <nt def="NT-SelectExpr">
 SelectExpr
 </nt>
 is treated as a
 whitespace-separated list of names; the set of names is the union for
 each node of the members of the list.
 
 </item>
 </ulist>
 
 The result is the set of element nodes whose ID (see
 <specref ref="unique-id"/>
 ) is one of the names in the set of names specified
 by the argument.
 
 <issue id="issue-class-attribute">
 
 Should there be a way of
 specifying that an attribute serves as a class attribute and then
 pattern syntax that treats class attributes specially?
 
 </issue>
 <scrap>
 <head>
 Ancestors
 </head>
 <prod id="NT-AncestorExpr">
 <lhs>
 AncestorExpr
 </lhs>
 <rhs>
 'ancestor('
 <nt def="NT-MatchExpr">
 MatchExpr
 </nt>
 ')'
 </rhs>
 </prod>
 </scrap>
 
 The result the first ancestor of the context of the
 <nt def="NT-AncestorExpr">
 AncestorExpr
 </nt>
 such that
 <nt def="NT-MatchExpr">
 MatchExpr
 </nt>
 , when evaluated with that ancestor
 as the context, has a result of true. If there is no such ancestor,
 the result is the empty node set.
 
 <scrap>
 <head>
 Identity
 </head>
 <prod id="NT-IdentityExpr">
 <lhs>
 IdentityExpr
 </lhs>
 <rhs>
 '.'
 </rhs>
 </prod>
 </scrap>
 
 The result is the context of the
 <nt def="NT-IdentityExpr">
 IdentityExpr
 </nt>
 .
 
 <scrap>
 <head>
 Parents
 </head>
 <prod id="NT-ParentExpr">
 <lhs>
 ParentExpr
 </lhs>
 <rhs>
 '..'
 </rhs>
 </prod>
 </scrap>
 
 The result is the parent of the context of the
 <nt def="NT-ParentExpr">
 ParentExpr
 </nt>
 . If the context is the root node,
 then the result is the empty node set.
 
 <scrap>
 <head>
 Boolean Expressions
 </head>
 <prod id="NT-BooleanExpr">
 <lhs>
 BooleanExpr
 </lhs>
 <rhs>
 <nt def="NT-AndExpr">
 AndExpr
 </nt>
 </rhs>
 <rhs>
 |
 <nt def="NT-OrExpr">
 OrExpr
 </nt>
 </rhs>
 <rhs>
 |
 <nt def="NT-BooleanPrimaryExpr">
 BooleanPrimaryExpr
 </nt>
 </rhs>
 </prod>
 <prod id="NT-BooleanPrimaryExpr">
 <lhs>
 BooleanPrimaryExpr
 </lhs>
 <rhs>
 <nt def="NT-BooleanGroupExpr">
 BooleanGroupExpr
 </nt>
 </rhs>
 <rhs>
 |
 <nt def="NT-NotExpr">
 NotExpr
 </nt>
 </rhs>
 <rhs>
 |
 <nt def="NT-PositionalExpr">
 PositionalExpr
 </nt>
 </rhs>
 <rhs>
 |
 <nt def="NT-TestExpr">
 TestExpr
 </nt>
 </rhs>
 <rhs>
 |
 <nt def="NT-EqualityExpr">
 EqualityExpr
 </nt>
 </rhs>
 </prod>
 </scrap>
 
 The result of a
 <nt def="NT-BooleanExpr">
 BooleanExpr
 </nt>
 is true
 or false. The context of the right hand side
 expressions is the context of the
 <nt def="NT-BooleanExpr">
 BooleanExpr
 </nt>
 . The result of the
 <nt def="NT-BooleanExpr">
 BooleanExpr
 </nt>
 is the result of the right hand
 side.
 
 <scrap>
 <head>
 And
 </head>
 <prod id="NT-AndExpr">
 <lhs>
 AndExpr
 </lhs>
 <rhs>
 <nt def="NT-BooleanPrimaryExpr">
 BooleanPrimaryExpr
 </nt>
 ( 'and'
 <nt def="NT-BooleanPrimaryExpr">
 BooleanPrimaryExpr
 </nt>
 )+
 </rhs>
 </prod>
 </scrap>
 
 The context for each
 <nt def="NT-BooleanPrimaryExpr">
 BooleanPrimaryExpr
 </nt>
 is the context of
 the
 <nt def="NT-AndExpr">
 AndExpr
 </nt>
 . The result is true if the
 result of all of the
 <nt def="NT-BooleanPrimaryExpr">
 BooleanPrimaryExpr
 </nt>
 s is true;
 otherwise the result is false.
 
 <scrap>
 <head>
 Or
 </head>
 <prod id="NT-OrExpr">
 <lhs>
 OrExpr
 </lhs>
 <rhs>
 <nt def="NT-BooleanPrimaryExpr">
 BooleanPrimaryExpr
 </nt>
 ( 'or'
 <nt def="NT-BooleanPrimaryExpr">
 BooleanPrimaryExpr
 </nt>
 )+
 </rhs>
 </prod>
 </scrap>
 
 The context for each
 <nt def="NT-BooleanPrimaryExpr">
 BooleanPrimaryExpr
 </nt>
 is the context of
 the
 <nt def="NT-OrExpr">
 OrExpr
 </nt>
 . The result is true if the result
 of any of the
 <nt def="NT-BooleanPrimaryExpr">
 BooleanPrimaryExpr
 </nt>
 s
 is true; otherwise the result is false.
 
 <scrap>
 <head>
 Grouping
 </head>
 <prod id="NT-BooleanGroupExpr">
 <lhs>
 BooleanGroupExpr
 </lhs>
 <rhs>
 '('
 <nt def="NT-BooleanExpr">
 BooleanExpr
 </nt>
 ')'
 </rhs>
 </prod>
 </scrap>
 
 The result of the left hand side is the result of the right hand
 side. The context of the right hand side is the context of the left
 hand side.
 
 <scrap>
 <head>
 Negation
 </head>
 <prod id="NT-NotExpr">
 <lhs>
 NotExpr
 </lhs>
 <rhs>
 'not('
 <nt def="NT-BooleanExpr">
 BooleanExpr
 </nt>
 ')'
 </rhs>
 </prod>
 </scrap>
 
 The result of the
 <nt def="NT-NotExpr">
 NotExpr
 </nt>
 is true if the
 result of the
 <nt def="NT-BooleanExpr">
 BooleanExpr
 </nt>
 is false;
 otherwise the result is false.
 
 <scrap>
 <head>
 Position
 </head>
 <prod id="NT-PositionalExpr">
 <lhs>
 PositionalExpr
 </lhs>
 <rhs>
 'first-of-type(' ')'
 </rhs>
 <rhs>
 | 'last-of-type(' ')'
 </rhs>
 <rhs>
 | 'first-of-any(' ')'
 </rhs>
 <rhs>
 | 'last-of-any(' ')'
 </rhs>
 </prod>
 </scrap>
 
 The context of the
 <nt def="NT-PositionalExpr">
 PositionalExpr
 </nt>
 is a single node.
 
 <ulist>
 <item>
 
 For
 <code>
 first-of-type()
 </code>
 , the result is true if the
 context node is an element and the element has no preceding siblings
 that are elements with the same element type name, and false
 otherwise.
 
 </item>
 <item>
 
 For
 <code>
 first-of-any()
 </code>
 , the result is true if the
 context node is an element and the element has no preceding siblings
 that are elements, and false otherwise.
 
 </item>
 <item>
 
 For
 <code>
 last-of-type()
 </code>
 , the result is true if the
 context node is an element and the element has no following siblings
 that are elements with the same element type name, and false
 otherwise.
 
 </item>
 <item>
 
 For
 <code>
 last-of-any()
 </code>
 , the result is true if the
 context node is an element and the element has no following siblings
 that are elements, and false
 otherwise.
 
 </item>
 </ulist>
 <scrap>
 <head>
 Testing Existence
 </head>
 <prod id="NT-TestExpr">
 <lhs>
 TestExpr
 </lhs>
 <rhs>
 <nt def="NT-SelectExpr">
 SelectExpr
 </nt>
 </rhs>
 </prod>
 </scrap>
 
 The context of the
 <nt def="NT-SelectExpr">
 SelectExpr
 </nt>
 is the
 context of the
 <nt def="NT-EqualityExpr">
 EqualityExpr
 </nt>
 . The
 result of the
 <nt def="NT-TestExpr">
 TestExpr
 </nt>
 is true if the
 result of the
 <nt def="NT-SelectExpr">
 SelectExpr
 </nt>
 is non-empty.
 Otherwise the result is false.
 
 <scrap>
 <head>
 Equality
 </head>
 <prod id="NT-EqualityExpr">
 <lhs>
 EqualityExpr
 </lhs>
 <rhs>
 <nt def="NT-SelectExpr">
 SelectExpr
 </nt>
 '='
 <nt def="NT-Literal">
 Literal
 </nt>
 </rhs>
 </prod>
 </scrap>
 
 The context of the
 <nt def="NT-SelectExpr">
 SelectExpr
 </nt>
 is the
 context of the
 <nt def="NT-EqualityExpr">
 EqualityExpr
 </nt>
 . The
 result is true if there is a node in the result of the
 <nt def="NT-SelectExpr">
 SelectExpr
 </nt>
 whose value is equal to the value
 of the
 <nt def="NT-Literal">
 Literal
 </nt>
 .
 
 <ednote>
 <edtext>
 We plan to use the data-typing facilities being
 developed by the XML Schema WG to allow ordered
 comparisons.
 </edtext>
 </ednote>
 <scrap>
 <head>
 Literal
 </head>
 <prod id="NT-Literal">
 <lhs>
 Literal
 </lhs>
 <rhs>
 '"' [^"]* '"'
 </rhs>
 <rhs>
 | "'" [^']* "'"
 </rhs>
 </prod>
 </scrap>
 
 The value of the
 <nt def="NT-Literal">
 Literal
 </nt>
 is the sequence
 of characters inside the
 <code>
 "
 </code>
 or
 <code>
 '
 </code>
 characters>.
 
 <scrap>
 <head>
 Pattern Lexical Structure
 </head>
 <prod id="NT-PatternToken">
 <lhs>
 PatternToken
 </lhs>
 <rhs>
 '/' | '@' | '(' | ')' | '|' | '[' | ']' | ',' | '=' | '.' | '..' | '*'
 </rhs>
 <rhs>
 | 'id(' | 'ancestor(' | 'comment(' | 'pi(' | 'text(' | 'not('
 </rhs>
 <rhs>
 | 'first-of-type('
 </rhs>
 <rhs>
 | 'last-of-type('
 </rhs>
 <rhs>
 | 'first-of-any('
 </rhs>
 <rhs>
 | 'last-of-any('
 </rhs>
 <rhs>
 |
 <xnt href="http://www.w3.org/TR/WD-xml-names#NT-QName">
 QName
 </xnt>
 </rhs>
 <rhs>
 |
 <nt def="NT-Literal">
 Literal
 </nt>
 </rhs>
 </prod>
 <prod id="NT-PatternWhitespace">
 <lhs>
 PatternWhitespace
 </lhs>
 <rhs>
 <xnt href="http://www.w3.org/TR/REC-xml#NT-S">
 S
 </xnt>
 </rhs>
 </prod>
 </scrap>
 
 For readability, whitespace may be used in patterns even though not
 explicitly allowed by the grammar:
 <nt def="NT-PatternWhitespace">
 PatternWhitespace
 </nt>
 may be freely added
 within patterns before or after any
 <nt def="NT-PatternToken">
 PatternToken
 </nt>
 .
 
 </div3>
 </div2>
 <div2>
 <head>
 Templates
 </head>
 <div3>
 <head>
 Overview
 </head>
 
 When the rule that is to be applied to the source element has been
 identified, the rule's template is instantiated. A
 template can contain literal result elements, character data and
 instructions for creating fragments of the result tree. Instructions
 are represented by elements in the XSL namespace.
 
 
 The
 <code>
 xsl:apply-templates
 </code>
 instruction can select
 descendant nodes for processing. Without any attribute, the
 <code>
 xsl:apply-templates
 </code>
 instruction processes the immediate
 children nodes of the source element; a
 <code>
 select
 </code>
 attribute
 can be used to process nodes selected by a specified pattern.
 
 <eg>
 <xsl:template match="chapter/title"> <fo:rule-graphic/> <fo:block space-before="2pt"> <xsl:text>Chapter </xsl:text> <xsl:number/> <xsl:text>: </xsl:text> <xsl:apply-templates/> </fo:block> <fo:rule-graphic/> </xsl:template>
 </eg>
 <issue id="issue-instruction-error">
 
 Should there be an instruction
 that generates an error, like the
 <code>
 error
 </code>
 procedure in
 DSSSL?
 
 </issue>
 <issue id="issue-multiple-results">
 
 Should it be possible to create
 multiple result trees?
 
 </issue>
 </div3>
 <div3>
 <head>
 Creating Elements and Attributes
 </head>
 <div4>
 <head>
 Literal Result Elements
 </head>
 
 In a template an element in the stylesheet that does not belong to
 the XSL namespace is instantiated to create an element node of the
 same type. The created element node will have the attribute nodes
 that were present on the element node in the stylesheet tree. The
 created element node will also have the namespace nodes that were
 present on the element node in the stylesheet tree with the exception
 of any namespace node whose value is the XSL namespace URI
 (
 <code>
 http://www.w3.org/TR/WD-xsl
 </code>
 ).
 
 
 The value of an attribute of a literal result element is
 interpreted as an
 <termref def="dt-attribute-value-template">
 attribute
 value template
 </termref>
 : it can contain string expressions contained
 in curly braces (
 <code>
 {}
 </code>
 ).
 
 
 Namespace URIs that occur literally in the stylesheet and that are
 being used to create nodes in the result tree can be quoted. This
 applies to:
 
 <ulist>
 <item>
 
 the namespace URI in the expanded name of an literal
 result element in the stylesheet
 
 </item>
 <item>
 
 the namespace URI in the expanded name of an attribute
 specified on a literal result element in the stylesheet
 
 </item>
 <item>
 
 the value of a namespace node on a literal result element in
 the stylesheet
 
 </item>
 </ulist>
 
 A namespace URI is quoted by prefixing it with the string
 <code>
 quote:
 </code>
 . This prefix will be removed when the template is
 instantiated to create the result element node with its associated
 attribute nodes and namespace nodes.
 
 
 When literal result elements are being used to create element,
 attribute and namespace nodes which use the XSL namespace URI, the
 namespace must be quoted to avoid misinterpretation by the XSL
 processor.
 
 <note>
 
 It may be necessary also to quote other namespaces. For
 example, literal result elements belonging to a namespace dealing with
 digital signatures might cause XSL stylesheets to mishandled by
 general purpose security software; quoting the namespace would avoid
 the possibility of such mishandling.
 
 </note>
 
 For example, the stylesheet
 
 <eg>
 <xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl" xmlns:fo="http://www.w3.org/TR/WD-xsl/FO" xmlns:qxsl="quote:http://www.w3.org/TR/WD-xsl"> <xsl:template match="/"> <qxsl:stylesheet> <xsl:apply-templates/> </qxsl:stylesheet> </xsl:template> <xsl:template match="block"> <qxsl:template match="{.}"> <fo:block><qxsl:apply-templates/></fo:block> </qxsl:template> </xsl:template> </xsl:stylesheet>
 </eg>
 
 will generate an XSL stylesheet from a document of the form:
 
 <eg>
 <elements> <block>p</block> <block>h1</block> <block>h2</block> <block>h3</block> <block>h4</block> </elements>
 </eg>
 </div4>
 <div4>
 <head>
 Named Attribute Sets
 </head>
 
 The
 <code>
 xsl:attribute-set
 </code>
 element defines a named set of
 attributes. The
 <code>
 name
 </code>
 attribute specifies the name of the
 attribute set. The content of the
 <code>
 xsl:attribute-set
 </code>
 element consists of
 <code>
 xsl:attribute
 </code>
 elements that specify
 attributes. A literal result element can specify an attribute set name
 as the value of the
 <code>
 xsl:use
 </code>
 attribute.
 
 
 The following example creates a named attribute set
 <code>
 title-style
 </code>
 and uses it in a template rule.
 
 <eg>
 <xsl:attribute-set name="title-style"> <xsl:attribute name="font-size">12pt</xsl:attribute> <xsl:attribute name="font-weight">bold</xsl:attribute> </xsl:attribute-set> <xsl:template match="chapter/heading"> <fo:block xsl:use="title-style" quadding="start"> <xsl:apply-templates/> </fo:block> </xsl:template>
 </eg>
 
 If the
 <code>
 xsl:use
 </code>
 attribute is specified on an element
 that also specifies a value for an attribute that is also part of the
 attribute set named by
 <code>
 xsl:use
 </code>
 , the attribute in the
 named attribute set is not used.
 
 
 Multiple definitions of an attribute set with the same name are
 merged. An attribute from a definition that is more
 <termref def="dt-important">
 important
 </termref>
 takes precedence over an
 attribute from a definition that is less
 <termref def="dt-important">
 important
 </termref>
 . It is an error if there are
 two attribute sets with the same name that are equally important and
 that both contain the same attribute unless there is a more
 <termref def="dt-important">
 important
 </termref>
 definition of the attribute set
 that also contains the attribute. An XSL processor may signal the
 error; if it does not signal the error, it must recover by choosing
 from amongst the most important definitions that specify the attribute
 the one that was specified last in the stylesheet.
 
 
 An
 <code>
 xsl:use
 </code>
 attribute may specify a list of attribute
 set names separated by whitespace. These attribute sets will be
 merged treating the list as being in order of increasing
 importance.
 
 </div4>
 <div4>
 <head>
 Creating Elements with
 <code>
 xsl:element
 </code>
 </head>
 
 The
 <code>
 xsl:element
 </code>
 allows an element to be created with a
 computed name. The
 <code>
 xsl:element
 </code>
 attribute has a required
 <code>
 name
 </code>
 attribute that specifies the name of the element.
 The
 <code>
 name
 </code>
 attribute is interpreted as an
 <termref def="dt-attribute-value-template">
 attribute value template
 </termref>
 .
 It is instantiated to create an element with the specified name. The
 content of the
 <code>
 xsl:element
 </code>
 element is a template for the
 attributes and children of the created element.
 
 
 The value of the
 <code>
 name
 </code>
 attribute after instantiation
 must have one of two forms:
 
 <ulist>
 <item>
 
 It can be a
 <xnt href="http://www.w3.org/TR/WD-xml-names#NT-QName">
 QName
 </xnt>
 . In
 this case the name is expanded in the same way as an element type name
 using the namespace declarations in scope for the
 <code>
 xsl:element
 </code>
 element in the stylesheet.
 
 </item>
 <item>
 
 It can be a namespace URI followed by a
 <code>
 #
 </code>
 character followed by an
 <xnt href="http://www.w3.org/TR/WD-xml-names#NT-NCName">
 NCName
 </xnt>
 . This can be used
 conjunction with a
 <nt def="NT-NameExpr">
 NameExpr
 </nt>
 to compute a
 qualified name.
 
 </item>
 </ulist>
 </div4>
 <div4>
 <head>
 Creating Attributes with
 <code>
 xsl:attribute
 </code>
 </head>
 
 The
 <code>
 xsl:attribute
 </code>
 element can be used to add
 attributes to result elements whether created by literal result
 elements in the stylesheet or by
 <code>
 xsl:element
 </code>
 elements.
 The
 <code>
 xsl:element
 </code>
 attribute has a required
 <code>
 name
 </code>
 attribute that specifies the name of the attribute.
 The
 <code>
 name
 </code>
 attribute is interpreted as an
 <termref def="dt-attribute-value-template">
 attribute value template
 </termref>
 It adds an attribute node to the containing result element node. The
 content of the
 <code>
 xsl:attribute
 </code>
 element is a template for
 the value of the created attribute.
 
 
 The following are all errors:
 
 <ulist>
 <item>
 
 Adding an attribute to an element after children have been
 added to it; implementations may either signal the error or ignore the
 attribute.
 
 </item>
 <item>
 
 Including nodes other than text nodes in the value of an
 attribute; implementations may either signal the error or ignore the
 added nodes.
 
 </item>
 <item>
 
 Adding an attribute that has the same name as an attribute
 already added; implementations may either signal the error or ignore
 the duplicate attribute.
 
 </item>
 <item>
 
 Adding an attribute to a node that is not an element;
 implementations may either signal the error or ignore the
 attribute.
 
 </item>
 </ulist>
 </div4>
 </div3>
 <div3>
 <head>
 Creating Text
 </head>
 
 A template can also contain text nodes. Each text node in a
 template remaining after whitespace has been stripped as specified in
 <specref ref="strip"/>
 will create a text node with the same value in
 the result tree. Adjacent text nodes in the result tree are
 automatically merged.
 
 
 Note that text is processed at the tree level. Thus, markup of
 <code>
 &
 lt;
 </code>
 in a template will be represented in the
 stylesheet tree by a text node that includes the character
 <code>
 <
 </code>
 . This will create a text node in the result tree
 that contains a
 <code>
 <
 </code>
 character, which will be represented
 by the markup
 <code>
 &
 lt;
 </code>
 (or an equivalent character
 reference) when the result tree is externalized as an XML
 document.
 
 
 Literal data characters may also be wrapped in an
 <code>
 xsl:text
 </code>
 element. This wrapping may change what
 whitespace characters are stripped (see
 <specref ref="strip"/>
 ) but
 does not affect how the characters are handled by the XSL processor
 thereafter.
 
 </div3>
 <div3>
 <head>
 Creating Processing Instructions
 </head>
 
 The
 <code>
 xsl:pi
 </code>
 element is instantiated to create a
 processing instruction node. The content of the
 <code>
 xsl:pi
 </code>
 element is a template for the value of the processing instruction
 node. The
 <code>
 xsl:pi
 </code>
 element has a required
 <code>
 name
 </code>
 attribute that specifies the name of the processing
 instruction node. The value of the name attribute is interpreted as
 an
 <termref def="dt-attribute-value-template">
 attribute value
 template
 </termref>
 .
 
 
 For example, this
 
 <eg>
 <xsl:pi name="xml-stylesheet">href="book.css" type="text/css"</xsl:pi>
 </eg>
 
 would create the processing instruction
 
 <eg>
 <?xml-stylesheet href="book.css" type="text/css"?>
 </eg>
 
 It is an error if instantiating the content of
 <code>
 xsl:pi
 </code>
 creates anything other than characters. An XSL processor may signal
 the error; if it does not signal the error, it must recover by
 ignoring the offending nodes together with their content.
 
 
 It is an error if the content of the
 <code>
 xsl:pi
 </code>
 contains
 the string
 <code>
 ?>
 </code>
 . An XSL processor may signal the error; if
 it does not signal the error, it must recover by inserting a space
 after any occurrence of
 <code>
 ?
 </code>
 that is followed by another
 <code>
 >
 </code>
 .
 
 </div3>
 <div3>
 <head>
 Creating Comments
 </head>
 
 The
 <code>
 xsl:comment
 </code>
 element is instantiated to create a
 comment node in the result tree. The content of the
 <code>
 xsl:comment
 </code>
 element is a template for the value of
 the comment node.
 
 
 For example, this
 
 <eg>
 <xsl:comment>This file is automatically generated. Do not edit!</xsl:comment>
 </eg>
 
 would create the comment
 
 <eg>
 
 </eg>
 
 It is an error if instantiating the content of
 <code>
 xsl:comment
 </code>
 creates anything other than characters. An
 XSL processor may signal the error; if it does not signal the error,
 it must recover by ignoring the offending nodes together with their
 content.
 
 
 It is an error if the content of the
 <code>
 xsl:comment
 </code>
 contains the string
 <code>
 --
 </code>
 . An XSL processor may signal the
 error; if it does not signal the error, it must recover by inserting a
 space after any occurrence of
 <code>
 -
 </code>
 that is followed by
 another
 <code>
 -
 </code>
 .
 
 </div3>
 <div3>
 <head id="children">
 Processing with Template Rules
 </head>
 
 This example creates a block for a
 <code>
 chapter
 </code>
 element and then processes its immediate children.
 
 <eg>
 <xsl:template match="chapter"> <fo:block> <xsl:apply-templates/> </fo:block> </xsl:template>
 </eg>
 
 In the absence of a
 <code>
 select
 </code>
 attribute, the
 <code>
 xsl:apply-templates
 </code>
 instruction processes all of the
 children of the current node, including text nodes. However, text
 nodes that have been stripped as specified in
 <specref ref="strip"/>
 will not be processed.
 
 <ednote>
 <edtext>
 There is no WG consensus on the use
 xsl:apply-templates without a select attribute to process all children
 of a node.
 </edtext>
 </ednote>
 
 A
 <code>
 select
 </code>
 attribute can be used to process nodes
 selected by a pattern instead of all children. The value of the
 <code>
 select
 </code>
 attribute is a
 <termref def="dt-select-pattern">
 select pattern
 </termref>
 . The following example processes all of
 the
 <code>
 author
 </code>
 children of the
 <code>
 author-group
 </code>
 :
 
 <eg>
 <xsl:template match="author-group"> <fo:sequence> <xsl:apply-templates select="author"/> </fo:sequence> </xsl:template>
 </eg>
 
 The pattern controls the depth at which matches occur. The
 following example processes all of the
 <code>
 first-name
 </code>
 s of the
 <code>
 author
 </code>
 s that are direct children of
 <code>
 author-group
 </code>
 :
 
 <eg>
 <xsl:template match="author-group"> <fo:sequence> <xsl:apply-templates select="author/first-name"/> </fo:sequence> </xsl:template>
 </eg>
 
 <code>
 //
 </code>
 can be used in the pattern to allow the matches to
 occur at arbitrary depths.
 
 
 This example processes all of the
 <code>
 heading
 </code>
 elements
 contained in the
 <code>
 book
 </code>
 element.
 
 <eg>
 <xsl:template match="book"> <fo:block> <xsl:apply-templates select=".//heading"/> </fo:block> </xsl:template>
 </eg>
 
 An
 <nt def="NT-AncestorExpr">
 AncestorExpr
 </nt>
 in the pattern
 allows the processing of elements that are not descendants of the
 current node. This example finds an employee's department and then
 processes the
 <code>
 group
 </code>
 children of the
 <code>
 department
 </code>
 .
 
 <eg>
 <xsl:template match="employee"> <fo:block> Employee <xsl:apply-templates select="name"/> belongs to group <xsl:apply-templates select="ancestor(department)/group"/> </fo:block> </xsl:template>
 </eg>
 
 This example assumes that a
 <code>
 department
 </code>
 element
 contains
 <code>
 group
 </code>
 and
 <code>
 employee
 </code>
 elements (at
 some level). When processing the
 <code>
 employee
 </code>
 elements, the
 <nt def="NT-AncestorExpr">
 AncestorExpr
 </nt>
 in the pattern allows
 navigation upward to the
 <code>
 department
 </code>
 element in order to
 extract the information about the group to which the employee
 belongs.
 
 
 An
 <nt def="NT-IdExpr">
 IdExpr
 </nt>
 allows processing of
 elements with a specific ID. For example, this template rule applies
 to elements with the ID
 <code>
 cfo
 </code>
 ; the second
 <code>
 xsl:apply-templates
 </code>
 element processes the
 <code>
 name
 </code>
 child of the element with ID
 <code>
 ceo
 </code>
 :
 
 <eg>
 <xsl:template match="id(cfo)"> <xsl:apply-templates select="name"/> reports to <xsl:apply-templates select="id(ceo)/name"/> </xsl:template>
 </eg>
 
 Multiple
 <code>
 xsl:apply-templates
 </code>
 elements can be used within a
 single template to do simple reordering. The following example
 creates two HTML tables. The first table is filled with domestic sales
 while the second table is filled with foreign sales.
 
 <eg>
 <xsl:template match="product"> <TABLE> <xsl:apply-templates select="sales/domestic"/> </TABLE> <TABLE> <xsl:apply-templates select="sales/foreign"/> </TABLE> </xsl:template>
 </eg>
 <note>
 
 It is possible for there to be two matching descendants where one
 is a descendant of the other. This case is not treated specially:
 both descendants will be processed as usual. For example, given a
 source document
 
 <eg>
 <doc><div><div></div></div></doc>
 </eg>
 
 the rule
 
 <eg>
 <xsl:template match="doc"> <xsl:apply-templates select=".//div"/> </xsl:template>
 </eg>
 
 will process both the outer
 <code>
 div
 </code>
 and inner
 <code>
 div
 </code>
 elements.
 
 </note>
 
 Use of select patterns in
 <code>
 xsl:apply-templates
 </code>
 can lead
 to infinite loops. It is an error if, during the invocation of a rule
 for an element, that same rule is invoked again for that element. An
 XSL processor may signal the error; if it does not signal the error,
 it must recover by creating an empty result tree structure for the
 nested invocation.
 
 <issue id="issue-select-function">
 
 What mechanisms should be
 provided for selecting elements for processing? For example, how can
 elements specified indirectly be handled? Suppose there's an
 <code>
 xref
 </code>
 element with a
 <code>
 ref
 </code>
 attribute that
 specifies the ID of a
 <code>
 div
 </code>
 element. The template
 for
 <code>
 xref
 </code>
 needs to select
 <code>
 title
 </code>
 child of the
 <code>
 div
 </code>
 element referenced by the
 <code>
 ref
 </code>
 attribute.
 Should it be possible to select elements in other XML
 documents?
 
 </issue>
 </div3>
 <div3>
 <head>
 Direct Processing
 </head>
 
 When the result has a known regular structure, it is useful to be
 able to specify directly the template for selected elements.
 The
 <code>
 xsl:for-each
 </code>
 element contains a template which
 is instantiated for each element selected by the pattern specified by
 the
 <code>
 select
 </code>
 attribute.
 
 <ednote>
 <edtext>
 Make it clear that it changes the current
 node.
 </edtext>
 </ednote>
 
 For example, given an XML document with this structure
 
 <eg>
 <customers> <customer> <name>...</name> <order>...</order> <order>...</order> </customer> <customer> <name>...</name> <order>...</order> <order>...</order> </customer> </customers>
 </eg>
 
 the following would create an HTML document containing a table with
 a row for each
 <code>
 customer
 </code>
 element
 
 <eg>
 <xsl:template match="/"> <HTML> <HEAD> <TITLE>Customers</TITLE> </HEAD> <BODY> <TABLE> <TBODY> <xsl:for-each select="customers/customer"> <TR> <TH> <xsl:apply-templates select="name"/> </TH> <xsl:for-each select="order"> <TD> <xsl:apply-templates/> </TD> </xsl:for-each> </TR> </xsl:for-each> </TBODY> </TABLE> </BODY> </HTML> </xsl:template>
 </eg>
 
 As with
 <code>
 xsl:apply-templates
 </code>
 the pattern is a
 <termref def="dt-select-pattern">
 select pattern
 </termref>
 . The
 <code>
 select
 </code>
 attribute is required.
 
 </div3>
 <div3>
 <head>
 Processing Modes
 </head>
 
 Processing modes allow an element to processed multiple times, each
 time producing a different result.
 
 
 Both
 <code>
 xsl:template
 </code>
 and
 <code>
 xsl:apply-templates
 </code>
 have an optional
 <code>
 mode
 </code>
 attribute whose value is a name.
 If an
 <code>
 xsl:apply-templates
 </code>
 element has a
 <code>
 mode
 </code>
 attribute, then it applies only those template rules from
 <code>
 xsl:template
 </code>
 elements that have a
 <code>
 mode
 </code>
 attribute with the same value; if an
 <code>
 xsl:apply-templates
 </code>
 element does not have a
 <code>
 mode
 </code>
 attribute, then it applies
 only those template rules from
 <code>
 xsl:template
 </code>
 elements that
 do not have a a
 <code>
 mode
 </code>
 attribute.
 
 
 If there is no matching template, then the built-in template rule
 is applied, even if a
 <code>
 mode
 </code>
 attribute was specified in
 <code>
 xsl:apply-templates
 </code>
 .
 
 <ednote>
 <edtext>
 Add some examples.
 </edtext>
 </ednote>
 </div3>
 <div3>
 <head>
 Sorting
 </head>
 
 Sorting is specified by adding
 <code>
 xsl:sort
 </code>
 elements as
 children of
 <code>
 xsl:apply-templates
 </code>
 or
 <code>
 xsl:for-each
 </code>
 . The first
 <code>
 xsl:sort
 </code>
 child
 specifies the primary sort key, the second
 <code>
 xsl:sort
 </code>
 child
 specifies the secondary sort key and so on. When
 <code>
 xsl:apply-templates
 </code>
 or
 <code>
 xsl:for-each
 </code>
 has one
 or more
 <code>
 xsl:sort
 </code>
 children, then instead of processing the
 selected elements in document order, it sorts the elements according
 to the specified sort keys and then processes them in sorted order.
 When used in
 <code>
 xsl:for-each
 </code>
 ,
 <code>
 xsl:sort
 </code>
 elements
 must occur first.
 
 
 <code>
 xsl:sort
 </code>
 has a
 <code>
 select
 </code>
 attribute whose
 value is a
 <termref def="dt-select-pattern">
 select pattern
 </termref>
 .
 For each node to be processed, the select pattern is evaluated with
 that node as the current node. The value of the first selected node is
 used as the sort key for that node. The default value of the code
 <code>
 select
 </code>
 attribute is
 <code>
 .
 </code>
 (which addresses the
 current element).
 
 
 This string serves as a sort key for the node. The following
 optional attributes on
 <code>
 xsl:sort
 </code>
 control how the list of
 sort keys are sorted:
 
 <ulist>
 <item>
 
 <code>
 order
 </code>
 specifies whether the strings should be
 sorted in ascending or descending order;
 <code>
 ascending
 </code>
 specifies ascending order;
 <code>
 descending
 </code>
 specifies
 descending order; the default is
 <code>
 ascending
 </code>
 
 </item>
 <item>
 
 <code>
 lang
 </code>
 specifies the language of the sort keys; it
 has the same range of values as
 <code>
 xml:lang
 </code>
 <bibref ref="XML"/>
 ; if no
 <code>
 lang
 </code>
 value is specified, the
 language should be determined from the system environment
 
 </item>
 <item>
 
 <code>
 data-type
 </code>
 specifies the data type of the
 strings; the following values are allowed
 
 <ulist>
 <item>
 
 <code>
 text
 </code>
 specifies that the sort keys should be
 sorted lexicograhically in the culturally correct manner for the
 language specified by
 <code>
 lang
 </code>
 
 </item>
 <item>
 
 <code>
 number
 </code>
 specifies that the sort keys should be
 converted to numbers and then sorted according to the numeric
 value; the value specified by
 <code>
 lang
 </code>
 can be used
 to assist in the conversion to numbers
 
 </item>
 </ulist>
 
 The default value is
 <code>
 text
 </code>
 .
 
 <ednote>
 <edtext>
 We plan to leverage the work on XML schemas to define
 further values in the future.
 </edtext>
 </ednote>
 </item>
 <item>
 
 <code>
 case-order
 </code>
 has the value
 <code>
 upper-first
 </code>
 or
 <code>
 lower-first
 </code>
 ; this applies
 when
 <code>
 data-type="text"
 </code>
 , and specifies that upper-case
 characters should sort before lower-case letters or vice-versa
 respectively. For example, if
 <code>
 lang="en"
 </code>
 then
 <code>
 A a B
 b
 </code>
 are sorted with
 <code>
 case-order="upper-first"
 </code>
 and
 <code>
 a A b B
 </code>
 are sorted with
 <code>
 case-order="lower-first"
 </code>
 . The default value is language
 dependent.
 
 </item>
 </ulist>
 <ednote>
 <edtext>
 We plan also to add an attribute whose value is a
 label identifying the sorting scheme, to be specified by the I18N
 WG.
 </edtext>
 </ednote>
 
 The values of all of the above attributes are interpreted as
 <termref def="dt-attribute-value-template">
 attribute value
 templates
 </termref>
 .
 
 <note>
 
 It is recommended that implementors consult
 <bibref ref="UNICODE-TR10"/>
 for information on internationalized
 sorting.
 
 </note>
 
 The sort must be stable: in the sorted list of nodes, any sublist
 that has sort keys that all compare equal must be in document
 order.
 
 
 For example, suppose an employee database has the form
 
 <eg>
 <employees> <employee> <name> <first>James</first> <last>Clark</last> </name> ... </employee> </employees>
 </eg>
 
 Then a list of employees sorted by name could be generated
 using:
 
 <eg>
 <xsl:template match="employees"> <ul> <xsl:apply-templates select="employee"> <xsl:sort select="name/last"/> <xsl:sort select="name/first"/> </xsl:apply-templates> </ul> </xsl:template> <xsl:template match="employee"> <li> <xsl:value-of select="name/first"/> <xsl:text> </xsl:text> <xsl:value-of select="name/last"/> </li> </xsl:template>
 </eg>
 </div3>
 <div3>
 <head>
 Numbering
 </head>
 <div4>
 <head>
 Numbering in the Source Tree
 </head>
 
 The
 <code>
 xsl:number
 </code>
 element does numbering based on the
 position of the current node in the source tree.
 
 
 The
 <code>
 xsl:number
 </code>
 element can have the following
 attributes:
 
 <ulist>
 <item>
 
 The
 <code>
 level
 </code>
 attribute specifies what levels of the
 source tree should be considered; it has the values
 <code>
 single
 </code>
 ,
 <code>
 multi
 </code>
 or
 <code>
 any
 </code>
 . The
 default is
 <code>
 single
 </code>
 .
 
 </item>
 <item>
 
 The
 <code>
 count
 </code>
 attribute is a
 <termref def="dt-match-pattern">
 match pattern
 </termref>
 that specifies what
 elements should be counted at those levels. The
 <code>
 count
 </code>
 attribute defaults to the element type name of the current
 node.
 
 </item>
 <item>
 
 The
 <code>
 from
 </code>
 attribute is a
 <termref def="dt-match-pattern">
 match pattern
 </termref>
 that specifies where
 counting starts from.
 
 </item>
 </ulist>
 
 In addition the
 <code>
 xsl:number
 </code>
 element has the attributes
 specified in
 <specref ref="convert"/>
 for number to string
 conversion.
 
 
 The
 <code>
 xsl:number
 </code>
 element first constructs a list of
 positive integers using the
 <code>
 level
 </code>
 ,
 <code>
 count
 </code>
 and
 <code>
 from
 </code>
 attributes:
 
 <ulist>
 <item>
 
 When
 <code>
 level="single"
 </code>
 , it goes up to the nearest
 ancestor (including the current node as its own ancestor) that
 matches the
 <code>
 count
 </code>
 pattern, and constructs a list of length one
 containing one plus the number of preceding siblings of that ancestor
 that match the
 <code>
 count
 </code>
 pattern. If there is no such
 ancestor, it constructs an empty list. If the
 <code>
 from
 </code>
 attribute is specified, then the only ancestors that are searched are
 those that are descendants of the nearest ancestor that matches the
 <code>
 from
 </code>
 pattern.
 
 </item>
 <item>
 
 When
 <code>
 level="multi"
 </code>
 , it constructs a list of all
 ancestors of the current node in document order followed by the
 element itself; it then selects from the list those elements that
 match the
 <code>
 count
 </code>
 pattern; it then maps each element of the
 list to one plus the number of preceding siblings of that element that
 match the
 <code>
 count
 </code>
 pattern. If the
 <code>
 from
 </code>
 attribute is specified, then the only ancestors that are searched are
 those that are descendants of the nearest ancestor that matches the
 <code>
 from
 </code>
 pattern.
 
 </item>
 <item>
 
 When
 <code>
 level="any"
 </code>
 , it constructs a list of length
 one containing one plus the number of elements at any level of the
 document that start before this node and that match the
 <code>
 count
 </code>
 pattern. If the
 <code>
 from
 </code>
 attribute is
 specified, then only elements after the first element before this
 element that match the
 <code>
 from
 </code>
 pattern are
 considered.
 
 </item>
 </ulist>
 
 The list of numbers is then converted into a string using the
 attributes specified in
 <specref ref="convert"/>
 ; when used with
 <code>
 xsl:number
 </code>
 the value of each of these attributes is
 interpreted as an
 <termref def="dt-attribute-value-template">
 attribute
 value template
 </termref>
 . After conversion, the resulting string is
 inserted in the result tree.
 
 <ednote>
 <edtext>
 Allowing them to be attribute value templates isn't
 consistent with the current DTD: the declared values would all have to
 be CDATA, and we couldn't use xml:lang because the XML spec doesn't
 allow the value to be expressed as a template.
 </edtext>
 </ednote>
 
 The following would number the items in an ordered list:
 
 <eg>
 <xsl:template match="ol/item"> <fo:block> <xsl:number/><xsl:text>. </xsl:text><xsl:apply-templates/> </fo:block> <xsl:template>
 </eg>
 
 The following two rules would number
 <code>
 title
 </code>
 elements.
 This is intended for a document that contains a sequence of chapters
 followed by a sequence of appendices, where both chapters and
 appendices contain sections which in turn contain subsections.
 Chapters are numbered 1, 2, 3; appendices are numbered A, B, C;
 sections in chapters are numbered 1.1, 1.2, 1.3; sections in
 appendices are numbered A.1, A.2, A.3.
 
 <eg>
 <xsl:template match="title"> <fo:block> <xsl:number level="multi" count="chapter|section|subsection" format="1.1. "/> <xsl:apply-templates/> </fo:block> </xsl:template> <xsl:template match="appendix//title" priority="1"> <fo:block> <xsl:number level="multi" count="appendix|section|subsection" format="A.1. "/> <xsl:apply-templates/> </fo:block> </xsl:template>
 </eg>
 
 The following example numbers notes sequentially within a
 chapter:
 
 <eg>
 <xsl:template match="note"> <fo:block> <xsl:number level="any" from="chapter" format="(1) "/> <xsl:apply-templates/> </fo:block> </xsl:template>
 </eg>
 
 The following example would number
 <code>
 H4
 </code>
 elements in HTML
 with a three-part label:
 
 <eg>
 <xsl:template match="H4"> <fo:block> <xsl:number level="any" from="H1" count="H2"/> <xsl:text>.</xsl:text> <xsl:number level="any" from="H2" count="H3"/> <xsl:text>.</xsl:text> <xsl:number level="any" from="H3" count="H4"/> <xsl:text> </xsl:text> <xsl:apply-templates/> </fo:block> </xsl:template>
 </eg>
 </div4>
 <div4>
 <head>
 Numbering in the Result Tree
 </head>
 
 The root node of the result and each result element has a set of
 named counters (a mapping from names to integers).
 
 
 Counter values are inserted using
 <code>
 xsl:counter
 </code>
 and
 <code>
 xsl:counters
 </code>
 elements. The name of the counter is
 specified with the
 <code>
 name
 </code>
 attribute.
 <code>
 xsl:counter
 </code>
 first constructs a list of length one
 containing the value of the named counter from the nearest ancestor in
 the result tree that has a counter with the specified name;
 <code>
 xsl:counters
 </code>
 first constructs a list containing, for each
 ancestor in the result tree that has a counter with the specified
 name, the value of named counter from that ancestor.
 <code>
 xsl:counter
 </code>
 and
 <code>
 xsl:counters
 </code>
 then convert
 the list of numbers into a string using the attributes specified in
 <specref ref="convert"/>
 ; when used with
 <code>
 xsl:counter
 </code>
 and
 <code>
 xsl:counters
 </code>
 the value of each of these attributes is
 interpreted as an
 <termref def="dt-attribute-value-template">
 attribute
 value template
 </termref>
 .
 
 
 Counters are incremented using the
 <code>
 xsl:counter-increment
 </code>
 element. The
 <code>
 name
 </code>
 attribute specifies the name of the counter to be incremented. It
 finds the nearest ancestor in the result tree that has a counter with
 the specified name and increments that; if there is no such ancestor,
 it adds a counter with a value of zero to the document root and then
 increments it. The counter is incremented by 1 by default, but this
 can be changed using the
 <code>
 amount
 </code>
 attribute.
 
 
 The
 <code>
 xsl:counter-reset
 </code>
 element sets the value of a
 counter in the current named counter set. The current named counter
 set is the set of named counters of the containing element in the
 result tree or of the document root if there is no containing element.
 If the current named counter set doesn't contain a counter of that
 name, a counter is added to it, otherwise the existing value is
 changed. The name of the counter to be set is specified by the
 <code>
 name
 </code>
 attribute. The value to set it to is specified by
 the
 <code>
 value
 </code>
 attribute; this defaults to 0.
 
 
 The
 <code>
 xsl:counter-scope
 </code>
 element is a phantom result
 element: it behaves just like a normal result element for the purposes
 of result numbering in that it is considered part of the result tree
 and has a set of named counters, but doesn't actually create a result
 element. This is for when the result tree doesn't have enough
 structure for counting.
 
 <note>
 
 The numbering may be performed in the tree construction
 process or may be left for the formatting process.
 
 </note>
 <note>
 
 These facilities for result tree numbering are based on the
 facilities for automatic numbering in
 <bibref ref="CSS2"/>
 .
 
 </note>
 
 The following example would number notes sequentially throughout a
 document:
 
 <eg>
 <xsl:template match="note"> <xsl:text> (Note </xsl:text> <xsl:counter-increment name="note"/> <xsl:counter name="note"/> <xsl:text>).</xsl:text> </xsl:template>
 </eg>
 
 The following would turn ordered lists into definition lists:
 
 <eg>
 <xsl:template match="OL"> <dl> <xsl:counter-reset name="li"/> <xsl:apply-templates/> </dl> </xsl:template> <xsl:template match="LI"> <xsl:counter-increment name="li"/> <dt><xsl:counter name="li"/></dt> <dd><xsl:apply-templates/></dd> </xsl:template>
 </eg>
 
 The following would do HTML style numbering:
 
 <eg>
 <xsl:template match="h2"> <xsl:counter-increment name="h2"/> <xsl:counter name="h2"/> <xsl:text>. </xsl:text> <xsl:apply-templates/> <xsl:counter-reset name="h3"/> </xsl:template> <xsl:template match="h3"> <xsl:counter-increment name="h3"/> <xsl:counter name="h2"/> <xsl:text>.</xsl:text> <xsl:counter name="h3"/> <xsl:text>. </xsl:text> <xsl:apply-templates/> <xsl:counter-reset name="h4"/> </xsl:template> <xsl:template match="h4"> <xsl:counter-increment name="h4"/> <xsl:counter name="h2"/> <xsl:text>.</xsl:text> <xsl:counter name="h3"/> <xsl:text>.</xsl:text> <xsl:counter name="h4"/> <xsl:text>.</xsl:text> <xsl:apply-templates/> </xsl:template>
 </eg>
 
 The following would deal with recursive divs each with a title child:
 
 <eg>
 <xsl:template match="div"> <div> <xsl:apply-templates/> </div> </xsl:template> <xsl:template match="title"> <xsl:counter-increment name="div"/> <xsl:counters name="div" format="1.1. "/> <xsl:apply-templates/> <xsl:counter-reset name="div"/> </xsl:template>
 </eg>
 </div4>
 <div4 id="convert">
 <head>
 Number to String Conversion Attributes
 </head>
 
 The following attributes are used to control conversion of a list
 of numbers into a string. The numbers are integers greater than
 0. The attributes are all optional.
 
 
 The main attribute is
 <code>
 format
 </code>
 . The default value for
 the
 <code>
 format
 </code>
 attribute is
 <code>
 1
 </code>
 . The
 <code>
 format
 </code>
 attribute is split into a sequence of tokens where
 each token is a maximal sequence of alphanumeric characters or a
 maximal sequence of non-alphanumeric characters. Alphanumeric means
 any character that has a Unicode category of Nd, Nl, No, Lu, Ll, Lt,
 Lm or Lo. The alphanumeric tokens (format tokens) specify the format
 to be used for each number in the list. If the first token is a
 non-alphanumeric token, then the constructed string will start with
 that token; if the last token is non-alphanumeric token, then the
 constructed string will end with that token. Non-alphanumeric tokens
 that occur between two format tokens are separator tokens that are
 used to join numbers in the list. The n-th format token will be used
 to format the n-th number in the list. If there are more numbers than
 format tokens, then the last format token will be used to format
 remaining numbers. If there are no format tokens, then a format token
 of
 <code>
 1
 </code>
 is used to format all numbers. The format token
 specifies the string to be used to represent the number 1. Each
 number after the first will be separated from the preceding number by
 the separator token preceding the format token used to format that
 number, or, if there are no separator tokens, then by
 <code>
 .
 </code>
 .
 
 
 Format tokens are a superset of the allowed values for the
 <code>
 type
 </code>
 attribute for the
 <code>
 OL
 </code>
 element in HTML
 4.0 and are interpreted as follows:
 
 <ulist>
 <item>
 
 Any token where the last character has a decimal digit value
 of 1 (as specified in the Unicode 2.0 character property database),
 and the Unicode value of preceding characters is one less than the
 Unicode value of the last character. This generates a decimal
 representation of the number where each number is at least as long as
 the format token. Thus a format token
 <code>
 1
 </code>
 generates the
 sequence
 <code>
 1 2 ... 10 11 12 ...
 </code>
 , and a format token
 <code>
 01
 </code>
 generates the sequence
 <code>
 01 02 ... 09 10 11 12
 ... 99 100 101
 </code>
 .
 
 </item>
 <item>
 
 A format token
 <code>
 A
 </code>
 generates the sequence
 <code>
 A
 B C ... Z AA AB AC...
 </code>
 .
 
 </item>
 <item>
 
 A format token
 <code>
 a
 </code>
 generates the sequence
 <code>
 a
 b c ... z aa ab ac...
 </code>
 .
 
 </item>
 <item>
 
 A format token
 <code>
 i
 </code>
 generates the sequence
 <code>
 i
 ii iii iv v vi vii vii ix x ...
 </code>
 .
 
 </item>
 <item>
 
 A format token
 <code>
 I
 </code>
 generates the sequence
 <code>
 I
 II III IV V VI VII VII IX X ...
 </code>
 .
 
 </item>
 <item>
 
 Any other format token indicates a numbering sequence that
 starts with that token. If an implementation does not support a
 numbering system that starts with that token, it must use a format
 token of
 <code>
 1
 </code>
 .
 
 </item>
 </ulist>
 
 When numbering with an alphabetic sequence, the
 <code>
 xml:lang
 </code>
 attribute specifies which language's alphabet is
 to be used.
 
 <note>
 
 This can be considered as specifying the language of the
 value of the
 <code>
 format
 </code>
 attribute and hence is consistent
 with the semantics of
 <code>
 xml:lang
 </code>
 .
 
 </note>
 
 The
 <code>
 letter-value
 </code>
 attribute disambiguates between
 numbering schemes that use letters. In many languages there are two
 commonly used numbering schemes that use letters. One numbering
 scheme assigns numeric values to letters in alphabetic sequence, and
 the other assigns numeric values to each letter in some other manner.
 In English, these would correspond to the numbering sequences
 specified by the format tokens
 <code>
 a
 </code>
 and
 <code>
 i
 </code>
 . In
 some languages the first member of each sequence is the same, and so
 the format token alone would be ambiguous. A value of
 <code>
 alphabetic
 </code>
 specifies the alphabetic sequence; a value of
 <code>
 other
 </code>
 specifies the other sequence.
 
 
 The
 <code>
 digit-group-sep
 </code>
 attribute gives the separator
 between groups of digits, and the optional
 <code>
 n-digits-per-group
 </code>
 specifies the number of digits per
 group. For example,
 <code>
 digit-group-sep=","
 </code>
 and
 <code>
 n-digits-per-group="3"
 </code>
 would produce numbers of the form
 <code>
 1,000,000
 </code>
 .
 
 
 The
 <code>
 sequence-src
 </code>
 attribute gives the URI of a text
 resource that contains a whitespace separated list of the members of
 the numbering sequence.
 
 <ednote>
 <edtext>
 Specify what should happen when the sequence runs
 out.
 </edtext>
 </ednote>
 
 Here are some examples of conversion specifications:
 
 <ulist>
 <item>
 
 <code>
 format="
 &
 #x30A2;"
 </code>
 specifies Katakana
 numbering
 
 </item>
 <item>
 
 <code>
 format="
 &
 #x30A4;"
 </code>
 specifies Katakana
 numbering in the
 <quote>
 iroha
 </quote>
 order
 
 </item>
 <item>
 
 <code>
 format="
 &
 #x0E51;"
 </code>
 specifies numbering with
 Thai digits
 
 </item>
 <item>
 
 <code>
 format="
 &
 #x05D0;" letter-value="other"
 </code>
 specifies
 <quote>
 traditional
 </quote>
 Hebrew numbering
 
 </item>
 <item>
 
 <code>
 format="
 &
 #x10D0;" letter-value="other"
 </code>
 specifies Georgian numbering
 
 </item>
 <item>
 
 <code>
 format="
 &
 #x03B1;" letter-value="other"
 </code>
 specifies
 <quote>
 classical
 </quote>
 Greek numbering
 
 </item>
 <item>
 
 <code>
 format="
 &
 #x0430;" letter-value="other"
 </code>
 specifies Old Slavic numbering
 
 </item>
 </ulist>
 </div4>
 </div3>
 <div3>
 <head>
 Conditionals within a Template
 </head>
 
 There are two instructions in XSL which support conditional
 processing in a template:
 <code>
 xsl:if
 </code>
 and
 <code>
 xsl:choose
 </code>
 . The
 <code>
 xsl:if
 </code>
 instruction provides
 simple if-then conditionality; the
 <code>
 xsl:choose
 </code>
 instruction
 supports selection of one choice when there are several
 possibilities.
 
 <div4>
 <head>
 Conditional Processing with
 <code>
 xsl:if
 </code>
 </head>
 
 The
 <code>
 xsl:if
 </code>
 element has a single attribute,
 <code>
 test
 </code>
 which specifies a
 <termref def="dt-select-pattern">
 select pattern
 </termref>
 . The content is a
 template. If the pattern selects a non-empty list of elements,
 then the content is instantiated; otherwise nothing is created. In
 the following example, the names in a group of names are formatted as
 a comma separated list:
 
 <eg>
 <xsl:template match="namelist/name"> <xsl:apply-templates/> <xsl:if test=".[not(last-of-type())]">, </xsl:if> </xsl:template>
 </eg>
 </div4>
 <div4>
 <head>
 Conditional Processing with
 <code>
 xsl:choose
 </code>
 </head>
 
 The
 <code>
 xsl:choose
 </code>
 element selects one among a number of
 possible alternatives. It consists of a series of
 <code>
 xsl:when
 </code>
 elements followed by an optional
 <code>
 xsl:otherwise
 </code>
 element. Each
 <code>
 xsl:when
 </code>
 element has a single attribute,
 <code>
 test
 </code>
 , which specifies a
 <termref def="dt-select-pattern">
 select pattern
 </termref>
 ; the test is
 treated as true if the pattern selects a non-empty list of elements.
 The content of the
 <code>
 xsl:when
 </code>
 and
 <code>
 xsl:otherwise
 </code>
 elements is a template. When an
 <code>
 xsl:choose
 </code>
 element is processed, each of the
 <code>
 xsl:when
 </code>
 elements is tested in turn. The content of the
 first, and only the first,
 <code>
 xsl:when
 </code>
 element whose test is
 true is instantiated. If no
 <code>
 xsl:when
 </code>
 is true, the
 content of the
 <code>
 xsl:otherwise
 </code>
 element is instantiated. If
 no
 <code>
 xsl:when
 </code>
 element is true, and no
 <code>
 xsl:otherwise
 </code>
 element is present, nothing is created.
 
 
 The following example enumerates items in an ordered list using
 arabic numerals, letters, or roman numerals depending on the depth to
 which the ordered lists are nested.
 
 <eg>
 <xsl:template match="orderedlist/listitem"> <fo:list-item indent-start='2pi'> <fo:list-item-label> <xsl:choose> <xsl:when test='ancestor(orderedlist/orderedlist)'> <xsl:number format="i"/> </xsl:when> <xsl:when test='ancestor(orderedlist)'> <xsl:number format="a"/> </xsl:when> <xsl:otherwise> <xsl:number format="1"/> </xsl:otherwise> </xsl:choose> <xsl:text>. </xsl:text> </fo:list-item-label> <fo:list-item-body> <xsl:apply-templates/> </fo:list-item-body> </fo:list-item> </xsl:template>
 </eg>
 </div4>
 </div3>
 <div3>
 <head>
 Copying
 </head>
 
 The
 <code>
 xsl:copy
 </code>
 element provides an easy way of copying
 the current node. The
 <code>
 xsl:copy
 </code>
 element is replaced by a
 copy of the current node. Only the children of the node are not
 automatically copied. Everything else about the current node,
 including the attribute nodes and the namespace nodes, are
 automatically copied. The content of the
 <code>
 xsl:copy
 </code>
 element is a template for the children of the created node; the
 content is not used for nodes of types that do not have children
 (attributes, text, comments and processing instructions).
 
 
 The root node is treated specially because the root node of the
 result tree is created implicitly. When the current node is the root
 node,
 <code>
 xsl:copy
 </code>
 will not create a root node, but will just
 use the content template.
 
 
 For example, the identity transformation can be written using
 <code>
 xsl:copy
 </code>
 :
 
 <eg>
 <xsl:template match="*|comment()|pi()"> <xsl:copy> <xsl:apply-templates/> </xsl:copy> </xsl:template>
 </eg>
 <issue id="issue-copy-attributes">
 
 Should there be some way for
 <code>
 xsl:copy
 </code>
 to control the copying of
 attributes?
 
 </issue>
 </div3>
 <div3 id="stringexpr">
 <head>
 Computing Generated Text
 </head>
 
 Within a template, the
 <code>
 xsl:value-of
 </code>
 element can
 be used to compute generated text, for example by extracting text from
 the source tree or by inserting the value of a string constant. The
 <code>
 xsl:value-of
 </code>
 element does this with a string expression
 that is specified as the value of the
 <code>
 select
 </code>
 attribute.
 String expressions can also be used inside attribute values of literal
 result elements by enclosing the string expression in curly brace
 (
 <code>
 {}
 </code>
 ).
 
 <div4>
 <head>
 String Expressions
 </head>
 <scrap>
 <head>
 String Expressions
 </head>
 <prod id="NT-StringExpr">
 <lhs>
 StringExpr
 </lhs>
 <rhs>
 <nt def="NT-SelectExpr">
 SelectExpr
 </nt>
 </rhs>
 <rhs>
 |
 <nt def="NT-NameExpr">
 NameExpr
 </nt>
 </rhs>
 <rhs>
 |
 <nt def="NT-ConstantRef">
 ConstantRef
 </nt>
 </rhs>
 <rhs>
 |
 <nt def="NT-MacroArgRef">
 MacroArgRef
 </nt>
 </rhs>
 </prod>
 </scrap>
 
 The value of a string expression that is a pattern is the value of
 the first node selected by the pattern. The value of each kind of
 node is described in
 <specref ref="data-model"/>
 . If no nodes are
 selected by the pattern, then the value is the empty string. The
 pattern is a
 <termref def="dt-select-pattern">
 select
 pattern
 </termref>
 .
 
 <issue id="issue-resolve-expr">
 
 Do we need a
 <code>
 resolve(pattern)
 </code>
 string expression that treats the
 characters as a relative URI and turns it into an absolute URI using
 the base URI of the addressed node?
 
 </issue>
 <scrap>
 <head>
 Name Expression
 </head>
 <prod id="NT-NameExpr">
 <lhs>
 NameExpr
 </lhs>
 <rhs>
 'name' '('
 <nt def="NT-SelectExpr">
 SelectExpr
 </nt>
 ')'
 </rhs>
 </prod>
 </scrap>
 
 The value of a
 <nt def="NT-NameExpr">
 NameExpr
 </nt>
 is the expanded
 name of the first node selected by the
 <nt def="NT-SelectExpr">
 SelectExpr
 </nt>
 . If no nodes are selected or the first
 node does not have a name, then the value is the empty string. If the
 expanded name has a null URI, then the value is just the local
 name. If the expanded name has a non-null URI, the the value is the
 URI followed by the character
 <code>
 #
 </code>
 followed by the local
 name.
 
 </div4>
 <div4>
 <head>
 Using String Expressions with
 <code>
 xsl:value-of
 </code>
 </head>
 
 The
 <code>
 xsl:value-of
 </code>
 element is replaced by the value of
 the string expression specified by the
 <code>
 select
 </code>
 attribute.
 The
 <code>
 select
 </code>
 attribute is required.
 
 
 For example, the following creates an HTML paragraph from a
 <code>
 person
 </code>
 element with
 <code>
 first-name
 </code>
 and
 <code>
 surname
 </code>
 attributes.
 
 <eg>
 <xsl:template match="person"> <xsl:value-of select="@first-name"/> <xsl:text> </xsl:text> <xsl:value-of select="@surname"/> </xsl:template>
 </eg>
 
 For example, the following creates an HTML paragraph from a
 <code>
 person
 </code>
 element with
 <code>
 first-name
 </code>
 and
 <code>
 surname
 </code>
 children elements.
 
 <eg>
 <xsl:template match="person"> <xsl:value-of select="first-name"/> <xsl:text> </xsl:text> <xsl:value-of select="surname"/> </xsl:template>
 </eg>
 
 The following precedes each
 <code>
 procedure
 </code>
 element with a
 paragraph containing the security level of the procedure. It assumes
 that the security level that applies to a procedure is determined by a
 <code>
 security
 </code>
 attribute on an ancestor element of the
 procedure. It also assumes that if more than one ancestor has a
 <code>
 security
 </code>
 attribute then the security level is determined
 by the closest such ancestor of the procedure.
 
 <eg>
 <xsl:template match="procedure"> <fo:block> <xsl:value-of select="ancestor(*[@security])/@security"/> </fo:block> <xsl:apply-templates/> </xsl:template>
 </eg>
 <issue id="issue-inherited-attribute">
 
 Unless an element counts as
 one of its own ancestors, using
 <code>
 ancestor(*[@security])/@security
 </code>
 won't work to get the inherited value of an attribute. We could
 either say
 <code>
 ancestor
 </code>
 always includes the current node;
 alternatively we could provide a variant of
 <code>
 ancestor
 </code>
 that
 does include the current node; alternatively we could provide a select
 pattern of the form
 <code>
 inherited-attribute('security')
 </code>
 .
 
 </issue>
 </div4>
 <div4 id="attribute-value-templates">
 <head>
 Attribute Value Templates
 </head>
 
 <termdef id="dt-attribute-value-template" term="Attribute Value Template">
 In an attribute value that is interpreted as an
 <term>
 attribute value template
 </term>
 , such as an attribute of a
 literal result element, string expressions can be used by surrounding
 the string expression with curly braces (
 <code>
 {}
 </code>
 )
 </termdef>
 .
 The attribute value template is instantiated by replacing the string
 expression together with surrounding curly braces by the value of the
 string expression.
 
 
 The following example creates an
 <code>
 IMG
 </code>
 result element
 from a
 <code>
 photograph
 </code>
 element in the source; the value of the
 <code>
 SRC
 </code>
 attribute of the
 <code>
 IMG
 </code>
 element is computed
 from the value of the
 <code>
 image-dir
 </code>
 constant and the content
 of the
 <code>
 href
 </code>
 child of the
 <code>
 photograph
 </code>
 element;
 the value of the
 <code>
 WIDTH
 </code>
 attribute of the
 <code>
 IMG
 </code>
 element is computed from the value of the the
 <code>
 width
 </code>
 attribute of the
 <code>
 size
 </code>
 child of the
 <code>
 photograph
 </code>
 element:
 
 <eg>
 <xsl:constant name="image-dir" value="/images"/> <xsl:template match="photograph"> <IMG SRC="{constant(image-dir)}/{href}" WIDTH="{size/@width}"/> </xsl:template>
 </eg>
 
 With this source
 
 <eg>
 <photograph> <href>headquarters.jpg</href> <size width="300"/> </photograph>
 </eg>
 
 the result would be
 
 <eg>
 <IMG SRC="/images/headquarters.jpg" WIDTH="300"/>
 </eg>
 
 When an attribute value template is instantiated, a double left or
 right curly brace outside a string expression will be replaced by a
 single curly brace. It is an error if a right curly brace occurs in
 an attribute value template outside a string expression without being
 followed by a second right curly brace; an XSL processor may signal
 the error or recover by treating the right curly brace as if it had
 been doubled. A right curly brace inside an
 <nt def="NT-Literal">
 Literal
 </nt>
 in a string expression is
 not recognized as terminating the string expression.
 
 
 Curly braces are
 <emph>
 not
 </emph>
 recognized recursively inside
 string expressions. For example:
 
 <eg role="error">
 <a href="#{id({@ref})/title}">
 </eg>
 
 is
 <emph>
 not
 </emph>
 allowed. Instead use simply:
 
 <eg>
 <a href="#{id(@ref)/title}">
 </eg>
 </div4>
 </div3>
 <div3>
 <head>
 String Constants
 </head>
 
 Global string constants may be defined using a
 <code>
 constant
 </code>
 element. The name attribute specifies
 the name of the constant, and the
 <code>
 value
 </code>
 attribute
 specified the value.
 
 
 A stylesheet must not contain more than one definition of a
 constant with the same name and same
 <termref def="dt-important">
 importance
 </termref>
 . A definition of a
 constant will not be used if there is another definition of a constant
 with the same name and higher
 <termref def="dt-important">
 importance
 </termref>
 .
 
 
 String constants are referenced using a
 <nt def="NT-ConstantRef">
 ConstantRef
 </nt>
 string expression.
 
 <scrap>
 <head>
 String Constant References
 </head>
 <prod id="NT-ConstantRef">
 <lhs>
 ConstantRef
 </lhs>
 <rhs>
 'constant' '('
 <xnt href="http://www.w3.org/TR/WD-xml-names#NT-NCName">
 NCName
 </xnt>
 ')'
 </rhs>
 </prod>
 </scrap>
 <eg>
 <xsl:constant name="para-font-size" value="12pt"/> <xsl:template match="para"> <fo:block font-size="{constant(para-font-size)}"> <xsl:apply-templates/> </fo:block> </xsl:template>
 </eg>
 <issue id="issue-local-constants">
 
 Should there be a way to define
 local constants?
 
 </issue>
 
 The
 <code>
 value
 </code>
 attribute is interpreted as an
 <termref def="dt-attribute-value-template">
 attribute value template
 </termref>
 .
 If the value of a constant definition
 <code>
 x
 </code>
 references a
 constant
 <code>
 y
 </code>
 , then the value for
 <code>
 y
 </code>
 must be
 computed before the value of
 <code>
 x
 </code>
 . It is an error if it is
 impossible to do this for all constant definitions because of
 dependency cycles.
 
 </div3>
 <div3>
 <head>
 Macros
 </head>
 <issue id="issue-macro-name">
 
 Should macros be called something
 else?
 
 </issue>
 
 Parts of templates can also be factored out of similar rules
 into macros for reuse. Macros allow authors to create aggregate
 result fragments and refer to the composite as if it were a single
 object. In this example, a macro is defined for a boxed paragraph
 with the word
 <quote>
 Warning!
 </quote>
 preceding the contents. The
 macro is referenced from a rule for
 <code>
 warning
 </code>
 elements.
 
 <eg>
 <xsl:macro name="warning-para"> <fo:block-level-box> <fo:block> <xsl:text>Warning! </xsl:text> <xsl:contents/> </fo:block> </fo:block-level-box> </xsl:macro> <xsl:template match="warning"> <xsl:invoke macro="warning-para"> <xsl:apply-templates/> </xsl-invoke> </xsl:template>
 </eg>
 
 Macros are defined using the
 <code>
 macro
 </code>
 element. The
 <code>
 name
 </code>
 attribute specifies the name of the macro being
 defined. The content of the
 <code>
 macro
 </code>
 element is a
 template, called the body of the macro. A macro is invoked
 using the
 <code>
 xsl:invoke
 </code>
 element; the content of
 <code>
 xsl:invoke
 </code>
 is a template. The name of the macro
 to be invoked is given by the
 <code>
 macro
 </code>
 attribute. Invoking a
 macro first instantiates the content of
 <code>
 xsl:invoke
 </code>
 . It
 then instantiates the body of the invoked macro passing it the result tree
 fragment created by the instantiation of the content of
 <code>
 xsl:invoke
 </code>
 ; this fragment can be inserted in the body of
 the macro using the
 <code>
 xsl:contents
 </code>
 element.
 
 
 Macros allow named arguments to be declared with the
 <code>
 xsl:macro-arg
 </code>
 element; the
 <code>
 name
 </code>
 attribute
 specifies the argument name, and the optional
 <code>
 default
 </code>
 attribute specifies the default value for the argument. Within the
 body of a macro, macro arguments are referenced using a
 <nt def="NT-MacroArgRef">
 MacroArgRef
 </nt>
 string expression. It is an
 error to refer to a macro argument that has not been declared. An XSL
 processor may signal the error; if it does not signal the error, it
 must recover by using an empty string. Arguments are supplied to a
 macro invocation using the code
 <code>
 xsl:arg
 </code>
 element; the
 <code>
 name
 </code>
 attribute specifies the argument name, and the
 <code>
 value
 </code>
 attribute specifies the argument value. It is an
 error to supply an argument to a macro invocation if the macro did not
 declare an argument of that name. An XSL processor may signal the
 error; if it does not signal the error, it must recover by ignoring
 the argument. The
 <code>
 value
 </code>
 attribute of
 <code>
 xsl:arg
 </code>
 and the
 <code>
 default
 </code>
 attribute of
 <code>
 xsl:macro-arg
 </code>
 are interpreted as
 <termref def="dt-attribute-value-template">
 attribute value templates
 </termref>
 ;
 they can contain string expressions in curly braces as with literal
 result elements.
 
 <scrap>
 <head>
 Macro Argument References
 </head>
 <prod id="NT-MacroArgRef">
 <lhs>
 MacroArgRef
 </lhs>
 <rhs>
 'arg' '('
 <xnt href="http://www.w3.org/TR/WD-xml-names#NT-NCName">
 NCName
 </xnt>
 ')'
 </rhs>
 </prod>
 </scrap>
 
 This example defines a macro for a
 <code>
 numbered-block
 </code>
 with
 an argument to control the format of the number.
 
 <eg>
 <xsl:macro name="numbered-block"> <xsl:macro-arg name="format" default="1. "/> <xsl:number format="{arg(format)}"/> <fo:block/> <xsl:contents/> </fo:block> </xsl:macro> <xsl:template match="appendix/title"> <xsl:invoke macro="numbered-block"> <xsl:arg name="format" value="A. "/> <xsl:apply-templates/> </xsl:invoke> </xsl:template>
 </eg>
 
 It is an error if a stylesheet contains more than one definition of
 a macro with the same name and same
 <termref def="dt-important">
 importance
 </termref>
 . An XSL processor may signal
 the error; if it does not signal the error, if must recover by
 choosing from amongst the definitions with highest importance the one
 that occurs last in the stylesheet.
 
 <issue id="issue-macro-arg-syntax">
 
 The proposal used the same
 element for declaring macro arguments and for invoking them. Should
 these be separate elements and if so what should they be
 called?
 
 </issue>
 </div3>
 </div2>
 <div2>
 <head>
 Combining Stylesheets
 </head>
 
 XSL provides two mechanisms to combine stylesheets:
 
 <slist>
 <sitem>
 an import mechanism that allows stylesheets to override each
 other, and
 </sitem>
 <sitem>
 an inclusion mechanism that allows stylesheets to be textually
 combined.
 </sitem>
 </slist>
 <div3 id="import">
 <head>
 Stylesheet Import
 </head>
 
 An XSL stylesheet may contain
 <code>
 xsl:import
 </code>
 elements. All
 the
 <code>
 xsl:import
 </code>
 elements must occur at the beginning of
 the stylesheet. The
 <code>
 xsl:import
 </code>
 element has an
 <code>
 href
 </code>
 attribute whose value is the URI of a stylesheet to
 be imported. A relative URI is resolved relative to the base URI of
 the
 <code>
 xsl:import
 </code>
 element (see
 <specref ref="base-uri"/>
 ).
 
 <eg>
 <xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl"> <xsl:import href="article.xsl"/> <xsl:import href="bigfont.xsl"/> <xsl:attribute-set name="note-style"> <xsl:attribute name="font-style">italic</xsl:attribute> </xsl:attribute-set> </xsl:stylesheet>
 </eg>
 
 <termdef id="dt-important" term="Important">
 Rules and definitions in
 the importing stylesheet are defined to be more
 <term>
 important
 </term>
 than rules and definitions in any imported stylesheets. Also rules
 and definitions in one imported stylesheet are defined to be more
 <term>
 important
 </term>
 than rules and definitions in previous imported
 stylesheets.
 </termdef>
 
 
 In general a more important rule or definition takes precedence
 over a less important rule or definition. This is defined in detail
 for each kind of rule and definition.
 
 <issue id="issue-stylesheet-partition">
 
 Should there be an XSL
 defined element that can be used to divide a stylesheet into parts,
 each of which is treated as if it were separately imported for
 precedence purposes?
 
 </issue>
 <issue id="issue-import-source">
 
 Provide a way for a stylesheet
 to import a stylesheet that is embedded in the document.
 
 </issue>
 <issue id="issue-import-media">
 
 Should we provide media-dependent
 imports as in CSS?
 
 </issue>
 <ednote>
 <edtext>
 Say something about the case where the same stylesheet
 gets imported twice. This should be treated the same as importing a
 stylesheet with the same content but different URIs. What about
 import loops?
 </edtext>
 </ednote>
 
 <code>
 xsl:apply-templates
 </code>
 processes the current node using
 only template rules that were imported into the stylesheet containing
 the current rule; the current node is processed in the current rule's
 mode.
 
 <ednote>
 <edtext>
 Expand this.
 </edtext>
 </ednote>
 </div3>
 <div3>
 <head>
 Stylesheet Inclusion
 </head>
 
 An XSL stylesheet may include another XSL stylesheet using an
 <code>
 xsl:include
 </code>
 element. The
 <code>
 xsl:include
 </code>
 element
 has an
 <code>
 href
 </code>
 attribute whose value is the URI of a
 stylesheet to be included. A relative URI is resolved relative to the
 base URI of the
 <code>
 xsl:include
 </code>
 element (see
 <specref ref="base-uri"/>
 ). The
 <code>
 xsl:include
 </code>
 element can occur as
 the child of the
 <code>
 xsl:stylesheet
 </code>
 element at any point
 after all
 <code>
 xsl:import
 </code>
 elements.
 
 
 The inclusion works at the XML tree level. The resource located by
 the
 <code>
 href
 </code>
 attribute value is parsed as an XML document,
 and the children of the
 <code>
 xsl:stylesheet
 </code>
 element in this
 document replace the
 <code>
 xsl:include
 </code>
 element in the including
 document. Also any
 <code>
 xsl:import
 </code>
 elements in the included
 document are moved up in the including document to after any existing
 <code>
 xsl:import
 </code>
 elements in the including document. Unlike
 with
 <code>
 xsl:import
 </code>
 , the fact that rules or definitions are
 included does not affect the way they are processed.
 
 <ednote>
 <edtext>
 What happens when a stylesheet directly or indirectly
 includes itself?
 </edtext>
 </ednote>
 </div3>
 <div3>
 <head>
 Embedding Stylesheets
 </head>
 
 Normally an XSL stylesheet is a complete XML document with the
 <code>
 xsl:stylesheet
 </code>
 element as the document element. However an XSL
 stylesheet may also be embedded in another resource. Two forms of
 embedding are possible:
 
 <slist>
 <sitem>
 the XSL stylesheet may be textually embedded in a non-XML
 resource, or
 </sitem>
 <sitem>
 the
 <code>
 xsl:stylesheet
 </code>
 element may occur in an XML
 document other than as the document element.
 </sitem>
 </slist>
 
 In the second case, the possibility arises of documents with inline
 style, that is documents that specify their own style. XSL does not
 define a specific mechanism for this. This is because this can be done
 by means of a general purpose mechanism for associating stylesheets
 with documents provided that:
 
 <slist>
 <sitem>
 the mechanism allows a part of a resource to be specified as
 the stylesheet, for example by using a URI with a fragment identifier,
 and
 </sitem>
 <sitem>
 the mechanism can itself can be embedded in the document, for
 example as a processing instruction.
 </sitem>
 </slist>
 
 It is not in the scope of XSL to define such a mechanism.
 
 <note>
 
 This is because the mechanism should be independent of any one stylesheet
 mechanism.
 
 </note>
 
 The xsl:stylesheet element may have an ID attribute that specifies a unique
 identifier.
 
 <note>
 
 In order for such an attribute to be used with the
 <code>
 id
 </code>
 XPointer location term, it must actually be declared
 in the DTD as being an ID.
 
 </note>
 
 The following example shows how inline style can be accomplished
 using the
 <code>
 xml-stylesheet
 </code>
 processing instruction mechanism
 for associating a stylesheet with an XML document. The URI uses an
 XPointer in a fragment identifier to locate the
 <code>
 xsl:stylesheet
 </code>
 element.
 
 <eg>
 <?xml version="1.0"?> <?xml-stylesheet type="text/xsl" href="#id(style1)"?> <!DOCTYPE doc SYSTEM "doc.dtd"> <doc> <head> <xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl" id="style1"> <xsl:import href="doc.xsl"/> <xsl:template match="id(foo)"> <fo:block font-weight="bold"><xsl:apply-templates/></fo:block> </xsl:template> </xsl:stylesheet> </head> <body> <para id="foo"> ... </para> </body> </doc>
 </eg>
 <note>
 
 The
 <code>
 type
 </code>
 pseudo-attribute in the
 <code>
 xml-stylesheet
 </code>
 processing instruction identifies the
 stylesheet language, not the content type of the resource of which the
 stylesheet is a part.
 
 </note>
 </div3>
 </div2>
 <div2>
 <head>
 Extensibility
 </head>
 
 This section will describe an extensibility mechanism for the tree
 construction process.
 
 <issue id="issue-construct-extensibility">
 
 Should there be some
 extensibility mechanism for the tree construction process? If so, how
 should it work? Should it be language independent?
 
 </issue>
 </div2>
 </div1>
 </body>
 <back>
 <div1>
 <head>
 DTD for XSL Stylesheets
 </head>
 
 The following entity can be used to construct a DTD for XSL
 stylesheets that create instances of a particular result DTD. Before
 referencing the entity, the stylesheet DTD must define a
 <code>
 result-elements
 </code>
 parameter entity listing the allowed
 result element types. For example:
 
 <eg>
 <!ENTITY % result-elements " | fo:sequence | fo:block ">
 </eg>
 <eg>
 <!ENTITY % instructions " | xsl:apply-templates | xsl:apply-imports | xsl:for-each | xsl:value-of | xsl:number | xsl:counter | xsl:counters | xsl:counter-increment | xsl:counter-reset | xsl:counter-scope | xsl:choose | xsl:if | xsl:contents | xsl:invoke | xsl:text | xsl:pi | xsl:comment | xsl:element | xsl:attribute | xsl:copy "> <!ENTITY % template " (#PCDATA %instructions; %result-elements;)* "> <!ENTITY % space-att "xml:space (default|preserve) #IMPLIED"> <!ELEMENT xsl:stylesheet (xsl:import*, (xsl:include | xsl:id | xsl:strip-space | xsl:preserve-space | xsl:macro | xsl:attribute-set | xsl:constant | xsl:template)*) > <!ATTLIST xsl:stylesheet result-ns NMTOKEN #IMPLIED default-space (preserve|strip) "preserve" indent-result (yes|no) "no" id ID #IMPLIED xmlns:xsl CDATA #FIXED "http://www.w3.org/TR/WD-xsl" %space-att; >  <!ENTITY % URI "CDATA">  <!ENTITY % pattern "CDATA">  <!ENTITY % priority "NMTOKEN"> <!ELEMENT xsl:import EMPTY> <!ATTLIST xsl:import href %URI; #REQUIRED> <!ELEMENT xsl:include EMPTY> <!ATTLIST xsl:include href %URI; #REQUIRED> <!ELEMENT xsl:id EMPTY> <!ATTLIST xsl:id attribute NMTOKEN #REQUIRED element NMTOKEN #IMPLIED > <!ELEMENT xsl:strip-space EMPTY> <!ATTLIST xsl:strip-space element NMTOKEN #REQUIRED> <!ELEMENT xsl:preserve-space EMPTY> <!ATTLIST xsl:preserve-space element NMTOKEN #REQUIRED> <!ELEMENT xsl:template %template;> <!ATTLIST xsl:template match %pattern; #REQUIRED priority %priority; #IMPLIED mode NMTOKEN #IMPLIED %space-att; > <!ELEMENT xsl:value-of EMPTY> <!ATTLIST xsl:value-of select CDATA #IMPLIED> <!ENTITY % conversion-atts ' format CDATA "1" xml:lang NMTOKEN #IMPLIED letter-value (alphabetic|other) #IMPLIED digit-group-sep CDATA #IMPLIED n-digits-per-group NMTOKEN #IMPLIED sequence-src %URI; #IMPLIED '> <!ELEMENT xsl:number EMPTY> <!ATTLIST xsl:number level (single|multi|any) "single" count CDATA #IMPLIED from CDATA #IMPLIED %conversion-atts; > <!ELEMENT xsl:counter EMPTY> <!ATTLIST xsl:counter name NMTOKEN #REQUIRED %conversion-atts; > <!ELEMENT xsl:counters EMPTY> <!ATTLIST xsl:counters name NMTOKEN #REQUIRED %conversion-atts; > <!ELEMENT xsl:counter-increment EMPTY> <!ATTLIST xsl:counter-increment name NMTOKEN #REQUIRED amount NMTOKEN #IMPLIED > <!ELEMENT xsl:counter-reset EMPTY> <!ATTLIST xsl:counter-reset name NMTOKEN #REQUIRED value NMTOKEN #IMPLIED > <!ELEMENT xsl:counter-scope %template;> <!ATTLIST xsl:counter-scope %space-att;> <!ELEMENT xsl:apply-templates (xsl:sort*)> <!ATTLIST xsl:apply-templates select %pattern; #IMPLIED mode NMTOKEN #IMPLIED > <!ELEMENT xsl:apply-imports EMPTY>  <!ELEMENT xsl:for-each (#PCDATA %instructions; %result-elements; | xsl:sort)* > <!ATTLIST xsl:for-each select %pattern; #REQUIRED %space-att; > <!ELEMENT xsl:sort EMPTY> <!ATTLIST xsl:sort select %pattern; "." lang CDATA #IMPLIED data-type (text|number) "text" order (ascending|descending) "ascending" case-order (upper-first|lower-first) #IMPLIED > <!ELEMENT xsl:if %template;> <!ATTLIST xsl:if test %pattern; #REQUIRED %space-att; > <!ELEMENT xsl:choose (xsl:when+, xsl:otherwise?)> <!ATTLIST xsl:choose %space-att;> <!ELEMENT xsl:when %template;> <!ATTLIST xsl:when test %pattern; #REQUIRED %space-att; > <!ELEMENT xsl:otherwise %template;> <!ATTLIST xsl:otherwise %space-att;> <!ELEMENT xsl:attribute-set (xsl:attribute)*> <!ATTLIST xsl:attribute-set name NMTOKEN #REQUIRED > <!ELEMENT xsl:constant EMPTY> <!ATTLIST xsl:constant name NMTOKEN #REQUIRED value CDATA #REQUIRED >  <!ELEMENT xsl:macro (#PCDATA %instructions; %result-elements; | xsl:macro-arg)* > <!ATTLIST xsl:macro name NMTOKEN #REQUIRED %space-att; > <!ELEMENT xsl:macro-arg EMPTY> <!ATTLIST xsl:macro-arg name NMTOKEN #REQUIRED default CDATA #IMPLIED >  <!ELEMENT xsl:contents EMPTY>  <!ELEMENT xsl:invoke (#PCDATA %instructions; %result-elements; | xsl:arg)* > <!ATTLIST xsl:invoke macro NMTOKEN #REQUIRED %space-att; > <!ELEMENT xsl:arg EMPTY> <!ATTLIST xsl:arg name NMTOKEN #REQUIRED value CDATA #REQUIRED > <!ELEMENT xsl:text (#PCDATA)> <!ATTLIST xsl:text %space-att;> <!ELEMENT xsl:pi %template;> <!ATTLIST xsl:pi name CDATA #REQUIRED %space-att; > <!ELEMENT xsl:element %template;> <!ATTLIST xsl:element name CDATA #REQUIRED %space-att; > <!ELEMENT xsl:attribute %template;> <!ATTLIST xsl:attribute name CDATA #REQUIRED %space-att; > <!ELEMENT xsl:comment %template;> <!ATTLIST xsl:comment %space-att;> <!ELEMENT xsl:copy %template;> <!ATTLIST xsl:copy %space-att;>
 </eg>
 </div1>
 <div1>
 <head>
 References
 </head>
 <div2>
 <head>
 Normative References
 </head>
 <blist>
 <bibl id="XML" key="W3C XML">
 World Wide Web Consortium.
 <emph>
 Extensible
 Markup Language (XML) 1.0.
 </emph>
 W3C Recommendation. See
 <loc href="http://www.w3.org/TR/1998/REC-xml-19980210">
 http://www.w3.org/TR/1998/REC-xml-19980210
 </loc>
 </bibl>
 <bibl id="XMLNAMES" key="W3C XML Names">
 World Wide Web
 Consortium.
 <emph>
 Namespaces in XML.
 </emph>
 W3C Working Draft. See
 <loc href="http://www.w3.org/TR/WD-xml-names">
 http://www.w3.org/TR/WD-xml-names
 </loc>
 </bibl>
 </blist>
 </div2>
 <div2>
 <head>
 Other References
 </head>
 <blist>
 <bibl id="CSS2" key="CSS2">
 World Wide Web Consortium.
 <emph>
 Cascading
 Style Sheets, level 2 (CSS2)
 </emph>
 . W3C Recommendation. See
 <loc href="http://www.w3.org/TR/1998/REC-CSS2-19980512">
 http://www.w3.org/TR/1998/REC-CSS2-19980512
 </loc>
 </bibl>
 <bibl id="DSSSL" key="DSSSL">
 International Organization
 for Standardization, International Electrotechnical Commission.
 <emph>
 ISO/IEC 10179:1996. Document Style Semantics and Specification
 Language (DSSSL)
 </emph>
 . International Standard.
 </bibl>
 <bibl id="UNICODE-TR10" key="UNICODE TR10">
 Unicode Consortium.
 <emph>
 Draft
 Unicode Technical Report #10. Unicode Collation Algorithm
 </emph>
 .
 Draft Unicode Technical Report. See
 <loc href="http://www.unicode.org/unicode/reports/tr10/index.html">
 http://www.unicode.org/unicode/reports/tr10/index.html
 </loc>
 .
 </bibl>
 <bibl id="XMLSTYLE" key="W3C XML Stylesheet">
 World Wide Web
 Consortium.
 <emph>
 Associating stylesheets with XML documents.
 </emph>
 W3C Working Draft. See
 <loc href="http://www.w3.org/TR/WD-xml-stylesheet">
 http://www.w3.org/TR/WD-xml-stylesheet
 </loc>
 </bibl>
 </blist>
 </div2>
 </div1>
 <inform-div1>
 <head>
 Examples
 </head>
 
 The following is a simple but complete stylesheet.
 
 <eg>
 <?xml version='1.0'?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl" xmlns:fo="http://www.w3.org/TR/WD-xsl/FO" result-ns="fo" indent-result="yes"> <xsl:template match='/'> <fo:page-sequence font-family="serif"> <fo:simple-page-master name='scrolling'/> <fo:queue queue-name='body'> <xsl:apply-templates/> </fo:queue> </fo:page-sequence> </xsl:template> <xsl:template match="title"> <fo:block font-weight="bold"> <xsl:apply-templates/> </fo:block> </xsl:template> <xsl:template match="p"> <fo:block> <xsl:apply-templates/> </fo:block> </xsl:template> <xsl:template match="emph"> <fo:sequence font-style="italic"> <xsl:apply-templates/> </fo:sequence> </xsl:template> </xsl:stylesheet>
 </eg>
 
 With the following source document
 
 <eg>
 <doc> <title>An example</title> This is a test. This is <emph>another</emph> test. </doc>
 </eg>
 
 it would produce the following result
 
 <eg>
 <fo:page-sequence xmlns:fo="http://www.w3.org/TR/WD-xsl/FO" font-family="serif"> <fo:simple-page-master name="scrolling"/> <fo:queue queue-name="body"> <fo:block font-weight="bold">An example</fo:block> <fo:block>This is a test.</fo:block> <fo:block>This is <fo:sequence font-style="italic">another</fo:sequence> test.</fo:block> </fo:queue> </fo:page-sequence>
 </eg>
 </inform-div1>
 <inform-div1>
 <head>
 Design Principles
 </head>
 
 In the design of any language, trade-offs in the solution space are
 necessary. To aid in making these trade-offs the follow design
 principles were used:
 
 <slist>
 <sitem>
 XSL should support browsing, printing, and interactive editing and
 design tools
 </sitem>
 <sitem>
 XSL should be capable of specifying presentations for traditional and
 Web environments
 </sitem>
 <sitem>
 XSL should support interaction with structured information, as well
 as presentation of it.
 </sitem>
 <sitem>
 XSL should support all kinds of structured information, including both
 data and documents.
 </sitem>
 <sitem>
 XSL should support both visual and non-visual presentations.
 </sitem>
 <sitem>
 XSL should be a declarative language.
 </sitem>
 <sitem>
 XSL should be optimized to provide simple specifications for common
 formatting tasks and not preclude more sophisticated formatting tasks.
 </sitem>
 <sitem>
 XSL should provide an extensibility mechanism
 </sitem>
 <sitem>
 The number of optional features in XSL should be kept to a minimum.
 </sitem>
 <sitem>
 XSL should provide the formatting functionality of
 <emph>
 at
 least
 </emph>
 DSSSL and CSS
 </sitem>
 <sitem>
 XSL should leverage other recommendations and standards, including
 XML, XLL, DOM, HTML and ECMAScript.
 </sitem>
 <sitem>
 XSL should be expressed in XML syntax.
 </sitem>
 <sitem>
 XSL stylesheets should be human-readable and reasonably clear.
 </sitem>
 <sitem>
 Terseness in XSL markup is of minimal importance.
 </sitem>
 </slist>
 </inform-div1>
 <inform-div1>
 <head>
 Acknowledgements
 </head>
 
 The following have contributed to authoring this draft:
 
 <slist>
 <sitem>
 Sharon Adler, Inso Corporation
 </sitem>
 <sitem>
 Anders Berglund, Inso Corporation
 </sitem>
 <sitem>
 Paul Grosso, ArborText
 </sitem>
 <sitem>
 Eduardo Gutentag, Sun Microsystems
 </sitem>
 <sitem>
 Chris Lilley, W3C
 </sitem>
 <sitem>
 Chris Maden, O'Reilly
 &
 Associates
 </sitem>
 <sitem>
 Jonathan Marsh, Microsoft Corporation
 </sitem>
 <sitem>
 Henry S. Thompson, University of Edinburgh
 </sitem>
 <sitem>
 Paul Trevithick, Bitstream
 </sitem>
 <sitem>
 Norman Walsh, ArborText
 </sitem>
 <sitem>
 Steve Zilles, Adobe
 </sitem>
 </slist>
 </inform-div1>
 <inform-div1>
 <head>
 Changes from Previous Public Working Draft
 </head>
 
 <code>
 xsl:process
 </code>
 and
 <code>
 xsl:process-children
 </code>
 have
 been combined into
 <code>
 xsl:apply-templates.
 </code>
 
 
 The
 <code>
 expr
 </code>
 attribute of
 <code>
 xsl:value-of
 </code>
 has
 been renamed to
 <code>
 select
 </code>
 .
 
 
 Support for comments has been added.
 
 
 Support for processing instructions has been added.
 
 
 Support for text nodes has been added.
 
 
 Support for result tree numbering has been added.
 
 
 Support for sorting has been added.
 
 
 The
 <code>
 xsl:copy
 </code>
 element has been added.
 
 
 The
 <code>
 xsl:element
 </code>
 element has been added.
 
 
 The
 <code>
 xsl:attribute
 </code>
 element has been added.
 
 
 Attribute patterns have been changed: the syntax is
 <code>
 @foo
 </code>
 rather than
 <code>
 attribute(foo)
 </code>
 ; they can be
 used as match patterns and select patterns;
 <code>
 @*
 </code>
 can be
 used to match all attributes.
 
 
 The argument to id() must now be quoted. Select patterns can also
 be used as an argument.
 
 
 The syntax for patterns has been reworked; it is now more general
 than before.
 
 
 The syntax for quoting namespaces has been changed.
 
 
 Specificity has been removed.
 
 
 Priorities can be real numbers.
 
 
 Support for processing modes has been added.
 
 
 <code>
 xsl:apply-imports
 </code>
 has been added.
 
 
 <code>
 define-
 </code>
 has been removed from the name of top-level
 elements.
 <code>
 xsl:attribute-set
 </code>
 now contains
 <code>
 xsl:attribute
 </code>
 elements.
 
 
 The default namespace (as declared with the
 <code>
 xmlns
 </code>
 attribute) is not used for element type names in patterns.
 
 </inform-div1>
 </back>
</spec>