summaryrefslogtreecommitdiff
path: root/info/examples/lwc/ch7/xsl.xml
diff options
context:
space:
mode:
authorNorbert Preining <norbert@preining.info>2019-09-02 13:46:59 +0900
committerNorbert Preining <norbert@preining.info>2019-09-02 13:46:59 +0900
commite0c6872cf40896c7be36b11dcc744620f10adf1d (patch)
tree60335e10d2f4354b0674ec22d7b53f0f8abee672 /info/examples/lwc/ch7/xsl.xml
Initial commit
Diffstat (limited to 'info/examples/lwc/ch7/xsl.xml')
-rw-r--r--info/examples/lwc/ch7/xsl.xml3838
1 files changed, 3838 insertions, 0 deletions
diff --git a/info/examples/lwc/ch7/xsl.xml b/info/examples/lwc/ch7/xsl.xml
new file mode 100644
index 0000000000..6cbab1f894
--- /dev/null
+++ b/info/examples/lwc/ch7/xsl.xml
@@ -0,0 +1,3838 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="stylesheet/xml.dsl" type="text/dsssl"?>
+<!-- $Id: xsl.xml 1.223 1998/12/02 10:12:01 jjc Exp $ -->
+<!DOCTYPE spec SYSTEM "xslspec.dtd" [
+<!ENTITY XMLRec "http://www.w3.org/TR/REC-xml">
+<!ENTITY XMLNames "http://www.w3.org/TR/WD-xml-names">
+<!ENTITY year "1998">
+<!ENTITY month "December">
+<!ENTITY day "2">
+<!ENTITY MMDD "1202">
+<!ENTITY fo SYSTEM "fo.xml">
+<!ENTITY D "DSSSL:">
+<!ENTITY C "CSS:">
+]>
+<spec>
+<header>
+<title>Extensible Stylesheet Language (XSL)</title>
+<version>Version 1.0</version>
+<w3c-designation>WD-xsl-&year;&MMDD;</w3c-designation>
+<w3c-doctype>World Wide Web Consortium Working Draft</w3c-doctype>
+<pubdate><day>&day;</day><month>&month;</month><year>&year;</year></pubdate>
+<publoc>
+<loc href="http://www.w3.org/TR/&year;/WD-xsl-&year;&MMDD;"
+ >http://www.w3.org/TR/&year;/WD-xsl-&year;&MMDD;</loc>
+<loc href="http://www.w3.org/TR/&year;/WD-xsl-&year;&MMDD;.xml"
+ >http://www.w3.org/TR/&year;/WD-xsl-&year;&MMDD;.xml</loc>
+<loc href="http://www.w3.org/TR/&year;/WD-xsl-&year;&MMDD;.html"
+ >http://www.w3.org/TR/&year;/WD-xsl-&year;&MMDD;.html</loc>
+<loc href="http://www.w3.org/TR/&year;/WD-xsl-&year;&MMDD;.pdf"
+ >http://www.w3.org/TR/&year;/WD-xsl-&year;&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:jjc@jclark.com">jjc@jclark.com</email>
+</author>
+<author part="Formatting Objects">
+<name>Stephen Deach</name>
+<affiliation>Adobe</affiliation>
+<email href="mailto:sdeach@adobe.com">sdeach@adobe.com</email>
+</author>
+</authlist>
+
+<status>
+
+<p>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>.</p>
+
+<p>Comments may be sent to <loc
+href="mailto:xsl-editors@w3.org">xsl-editors@w3.org</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.</p>
+
+</status>
+
+<abstract>
+
+<p>XSL is a language for expressing stylesheets. It consists of two
+parts:</p>
+
+<olist>
+
+<item><p>a language for transforming XML documents, and</p></item>
+
+<item><p>an XML vocabulary for specifying formatting
+semantics.</p></item>
+
+</olist>
+
+<p>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.</p>
+
+</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>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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"/>.</p>
+
+</div1>
+
+<div1>
+<head>Tree Construction</head>
+
+<div2>
+<head>Overview</head>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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"/>.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<eg><![CDATA[<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>
+
+<p>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.</p>
+
+</div2>
+
+<div2>
+<head>Stylesheet Structure</head>
+
+<p>A stylesheet is represented by an <code>xsl:stylesheet</code>
+element in an XML document.</p>
+
+<p>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.</p>
+
+<issue id="issue-versioning"><p>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?</p></issue>
+
+<p>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.</p>
+
+<note><p>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,</p>
+
+<eg><![CDATA[
+<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>
+
+<p>The <code>xsl:stylesheet</code> element may contain the following types
+of elements:</p>
+<olist>
+<item><p><code>xsl:import</code></p></item>
+<item><p><code>xsl:include</code></p></item>
+<item><p><code>xsl:id</code></p></item>
+<item><p><code>xsl:strip-space</code></p></item>
+<item><p><code>xsl:preserve-space</code></p></item>
+<item><p><code>xsl:macro</code></p></item>
+<item><p><code>xsl:attribute-set</code></p></item>
+<item><p><code>xsl:constant</code></p></item>
+<item><p><code>xsl:template</code></p></item>
+</olist>
+
+<p>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.</p>
+
+<eg><![CDATA[<?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>
+
+<p>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.</p>
+
+<issue id="issue-media-rule"><p>Should we provide the functionality
+of CSS's <code>@media</code> rule and if so how?</p></issue>
+
+</div2>
+
+<div2>
+<head>Processing Model</head>
+
+<ednote><edtext>This needs expanding and polishing.</edtext></ednote>
+
+<p>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.</p>
+
+<p>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.</p>
+
+</div2>
+
+<div2 id="data-model">
+<head>Data Model</head>
+
+<p>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.</p>
+
+<p>XML documents operated on by XSL must conform to the XML namespaces
+specification <bibref ref="XMLNAMES"/>.</p>
+
+<p>The tree contains nodes. There are seven kinds of node:</p>
+
+<ulist>
+
+<item><p>root nodes</p></item>
+
+<item><p>element nodes</p></item>
+
+<item><p>text nodes</p></item>
+
+<item><p>attribute nodes</p></item>
+
+<item><p>namespace nodes</p></item>
+
+<item><p>processing instruction nodes</p></item>
+
+<item><p>comment nodes</p></item>
+
+</ulist>
+
+<p>Neither processing instruction nodes nor comment nodes are included
+in the tree for the stylesheet.</p>
+
+<p>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.</p>
+
+<issue id="issue-data-entity"><p>Should XSL provide support for
+external data entities and notations?</p></issue>
+
+<div3 id="root-node">
+<head>Root Node</head>
+
+<p>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.</p>
+
+<p>The <term>value</term> of the root node is the value of the
+document element.</p>
+
+</div3>
+
+<div3 id="element-nodes">
+<head>Element Nodes</head>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p><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></p>
+
+<p>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.</p>
+
+<p><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></p>
+
+<div4 id="unique-id">
+<head>Unique IDs</head>
+
+<p>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.</p>
+
+<eg><![CDATA[<xsl:id attribute="name"/>]]></eg>
+
+<p>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.</p>
+
+<issue id="unique-id-content"><p>Should it be possible for a unique id
+to be specified in the content of an element instead of in an
+attribute?</p></issue>
+
+</div4>
+
+<div4 id="base-uri">
+
+<head>Base URI</head>
+
+<p>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.</p>
+
+</div4>
+
+</div3>
+
+<div3 id="attribute-nodes">
+<head>Attribute Nodes</head>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>There are no attribute nodes for attributes that declare namespaces
+(see <bibref ref="XMLNAMES"/>).</p>
+
+<issue id="issue-external-dtd"><p>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?</p></issue>
+
+</div3>
+
+<div3 id="namespace-nodes">
+<head>Namespace Nodes</head>
+
+<p>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:</p>
+
+<ulist>
+
+<item><p>for every attribute on the element whose name starts with
+<code>xmlns:</code>;</p></item>
+
+<item><p>for every attribute on an ancestor element whose name starts
+<code>xmlns:</code> unless the element itself or a nearer ancestor
+redeclares the prefix;</p></item>
+
+<item>
+
+<p>for an <code>xmlns</code> attribute, unless its value is the empty
+string.</p>
+
+<note><p>An attribute <code>xmlns=""</code> <quote>undeclares</quote>
+the default namespace (see <bibref ref="XMLNAMES"/>).</p></note>
+
+</item>
+
+</ulist>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<note><p>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.</p></note>
+
+</div3>
+
+
+<div3>
+<head>Processing Instruction Nodes</head>
+
+<p>There is a processing instruction node for every processing
+instruction.</p>
+
+<ednote><edtext>What about processing instructions in the internal
+subset or elsewhere in the DTD?</edtext></ednote>
+
+<p>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>?&gt;</code>.</p>
+
+</div3>
+
+<div3>
+<head>Comment Nodes</head>
+
+<p>There is a comment node for every comment.</p>
+
+<ednote><edtext>What about comments in the internal subset or
+elsewhere in the DTD?</edtext></ednote>
+
+<p>A comment has a value. This is a string equal to the text of the
+comment not including the opening <code>&lt;!--</code> or the closing
+<code>--&gt;</code>.</p>
+
+</div3>
+
+<div3>
+<head>Text Nodes</head>
+
+<p>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.</p>
+
+<p>Each character within
+a CDATA section is treated as character data. Thus
+<code>&lt;![CDATA[&lt;]]&gt;</code> in the source document will
+treated the same as <code>&amp;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"/>.</p>
+
+</div3>
+
+<div3 id="strip">
+<head>Whitespace Stripping</head>
+
+<p>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.</p>
+
+<p>A text node is preserved if any of the following apply:</p>
+
+<ulist>
+
+<item><p>The element type of the parent of the text node is in the set
+of whitespace-preserving element types.</p></item>
+
+<item><p>The text node contains at least one non-whitespace character.
+As in XML, a whitespace character is #x20, #x9, #xD or #xA.</p></item>
+
+<item><p>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>.</p></item>
+
+</ulist>
+
+<p>Otherwise the text node is stripped.</p>
+
+<p>The <code>xml:space</code> attributes are not stripped from the
+tree.</p>
+
+<note><p>This implies that if an <code>xml:space</code> attribute is
+specified on a literal result element, it will be included in the
+result.</p></note>
+
+<p>For stylesheets, the set of whitespace-preserving element types
+consists of just <code>xsl:text</code><!-- and <code>fo:text</code>-->.</p>
+
+<!--<note><p><code>fo:text</code> is a formatting object that can contain
+only characters. Whereas characters outside <code>fo:text</code> are
+subject to the XSL-defined whitespace-related formatting properties
+(such as collapsing adjacent whitespace characters) in the same way as
+characters in the source document, whitespace characters occurring in
+<code>fo:text</code> will not be collapsed or stripped by the
+formatter.</p></note>-->
+
+<p>For source documents, the set of whitespace-preserving element
+types is determined using the stylesheet as follows:</p>
+
+<ulist>
+
+<item><p>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.</p></item>
+
+<item><p>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.</p></item>
+
+<item><p>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.</p></item>
+
+</ulist>
+
+<issue id="issue-declare-multiple-elements"><p>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?</p></issue>
+
+<ednote><edtext>Clarify how these declarations interact with each
+other and with xsl:import.</edtext></ednote>
+
+<p>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><!-- and
+<code>fo:text</code>-->.</p>
+
+</div3>
+
+</div2>
+
+<div2>
+<head>Template Rules</head>
+
+<p>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.</p>
+
+<p>For example, an XML document might contain:</p>
+
+<eg><![CDATA[This is an <emph>important</emph> point.]]></eg>
+
+<p>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>.</p>
+
+<eg><![CDATA[<xsl:template match="emph">
+ <fo:sequence font-weight="bold">
+ <xsl:apply-templates/>
+ </fo:sequence>
+</xsl:template>
+]]></eg>
+
+<p>As described later, the <code>xsl:apply-templates</code> element
+recursively processes the children of the source element.</p>
+
+<div3 id="conflict">
+<head>Conflict Resolution for Template Rules</head>
+
+<p>It is possible for a source node to match more than one
+template rule. The template rule to be used is determined as
+follows:</p>
+
+<olist>
+
+<item><p>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.</p></item>
+
+<item><p>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.</p>
+
+<ednote><edtext>Say exactly what syntax is allowed for real
+numbers.</edtext></ednote>
+
+</item>
+
+</olist>
+
+<p>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.</p>
+
+</div3>
+
+<div3>
+<head>Built-in Template Rule</head>
+
+<p>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:</p>
+
+<eg><![CDATA[<xsl:template match="*|/">
+ <xsl:apply-templates/>
+</xsl:template>]]></eg>
+
+<p>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>.</p>
+
+<p>There is also a built-in template rule for text nodes
+that copies text through:</p>
+
+<eg><![CDATA[<xsl:template match="text()">
+ <xsl:value-of select="."/>
+</xsl:template>]]></eg>
+
+<p>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.</p>
+
+</div3>
+</div2>
+
+<div2>
+<head>Patterns</head>
+
+<div3>
+<head>Introduction</head>
+
+<p>This section introduces the syntax and semantics of XSL patterns.
+The formal, definitive specification is in the following section.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p><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.</p>
+
+<p>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>.</p>
+
+<p><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.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>Other types of node are treated in a similar way to elements.</p>
+
+<ulist>
+
+<item><p>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.</p></item>
+
+<item><p>A pattern <code>comment()</code> selects all comment children
+of the current node. Thus a pattern <code>comment()</code> will match
+any comment node.</p></item>
+
+<item><p>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.</p></item>
+
+</ulist>
+
+<p>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:</p>
+
+<ulist>
+
+<item><p>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.</p></item>
+
+<item><p>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>.</p></item>
+
+<item><p>The position of a node relative to its siblings can be
+tested.</p>
+
+<ulist>
+
+<item><p><code>first-of-any()</code> succeeds if the node being tested
+is the first element child</p></item>
+
+<item><p><code>last-of-any()</code> succeeds if the node being tested
+is the last element child</p></item>
+
+<item><p><code>first-of-type()</code> succeeds if the node being
+tested is the first element child of its element type</p></item>
+
+<item><p><code>last-of-type()</code> succeeds if the node being
+tested is the first element child of its element type</p></item>
+
+</ulist>
+
+</item>
+
+<item><p>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.</p></item>
+
+<item><p>Tests can be combined with <code>and</code> and
+<code>or</code>. For example,</p>
+
+<eg>back/div[first-of-type() and last-of-type()]</eg>
+
+<p>matches a <code>div</code> element with a <code>back</code> parent,
+when it is the only <code>div</code> child of its parent.</p>
+</item>
+
+</ulist>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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>.</p>
+
+<p>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.</p>
+
+<ednote><edtext>Would it be less confusing to call this
+idref?</edtext></ednote>
+
+</div3>
+
+<div3>
+<head>Syntax and Semantics</head>
+
+<p>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.</p>
+
+<p>In the following grammar, the nonterminal <xnt
+href="&XMLNames;#NT-QName">QName</xnt> is defined in <bibref
+ref="XMLNAMES"/>, and <xnt href="&XMLRec;#NT-S">S</xnt> is defined in
+<bibref ref="XML"/>.</p>
+
+<scrap>
+<head>Selecting</head>
+<prod id="NT-SelectExpr">
+<lhs>SelectExpr</lhs>
+<rhs><nt def="NT-UnionExpr">UnionExpr</nt></rhs>
+</prod>
+</scrap>
+
+<p><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></p>
+
+<scrap>
+<head>Matching</head>
+<prod id="NT-MatchExpr">
+<lhs>MatchExpr</lhs>
+<rhs><nt def="NT-SelectExpr">SelectExpr</nt></rhs>
+</prod>
+</scrap>
+
+<p><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></p>
+
+<p>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.</p>
+
+<p>For implementation reasons, the functionality of <nt
+def="NT-MatchExpr">MatchExpr</nt>s is restricted as follows:</p>
+
+<ulist>
+
+<item><p>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.</p></item>
+
+<item><p>Within a <nt def="NT-MatchExpr">MatchExpr</nt>, an <nt
+def="NT-OtherNodeExpr">OtherNodeExpr</nt> must be a <nt
+def="NT-ConstantIdExpr">ConstantIdExpr</nt>.</p></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>
+
+<p>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.</p>
+
+<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>
+
+<p>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.</p>
+
+<scrap>
+<head>Absolute Paths</head>
+<prod id="NT-AbsolutePathExpr">
+<lhs>AbsolutePathExpr</lhs>
+<rhs>'/' <nt def="NT-SubtreeExpr">SubtreeExpr</nt>?</rhs>
+</prod>
+</scrap>
+
+<p>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.</p>
+
+<scrap>
+<head>Subtrees</head>
+<prod id="NT-SubtreeExpr">
+<lhs>SubtreeExpr</lhs>
+<rhs>'/'? <nt def="NT-ComposeExpr">ComposeExpr</nt></rhs>
+</prod>
+</scrap>
+
+<p>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>.</p>
+
+<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>
+
+<p>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>.</p>
+
+<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>
+
+<p>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.</p>
+
+<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>
+
+<p>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.</p>
+
+<issue id="issue-multiple-sources"><p>Should it be possible for
+patterns to select nodes in documents other than the source
+document?</p></issue>
+
+<issue id="issue-sibling-qual"><p>Should there be qualifiers that
+constrain an element to have an immediately preceding or following
+sibling of a particular type?</p></issue>
+
+<scrap>
+<head>Elements</head>
+<prod id="NT-ElementExpr">
+<lhs>ElementExpr</lhs>
+<rhs><xnt href="&XMLNames;#NT-QName">QName</xnt></rhs>
+<rhs>| '*'</rhs>
+</prod>
+</scrap>
+
+<p>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="&XMLNames;#NT-QName">QName</xnt>.</p>
+
+<p>When comparing the name of an element to a <xnt
+href="&XMLNames;#NT-QName">QName</xnt>, the <xnt
+href="&XMLNames;#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="&XMLNames;#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"/>).</p>
+
+<issue id="issue-pattern-namespace-wildcards"><p>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?</p></issue>
+
+<scrap>
+<head>Attributes</head>
+<prod id="NT-AttributeExpr">
+<lhs>AttributeExpr</lhs>
+<rhs>('@' <xnt href="&XMLNames;#NT-QName">QName</xnt>)</rhs>
+<rhs>| ('@' '*')</rhs>
+</prod>
+</scrap>
+
+<p>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="&XMLNames;#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="&XMLNames;#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="&XMLNames;#NT-QName">QName</xnt> is expanded in the same way as
+a <xnt href="&XMLNames;#NT-QName">QName</xnt> in an <nt
+def="NT-ElementExpr">ElementExpr</nt>.</p>
+
+<issue id="issue-attribute-qual-case"><p>Do we need to be able
+to match attributes in a case insensitive way?</p></issue>
+
+<scrap>
+<head>Processing Instructions</head>
+<prod id="NT-PiExpr">
+<lhs>PiExpr</lhs>
+<rhs>'pi(' <nt def="NT-Literal">Literal</nt>? ')'</rhs>
+</prod>
+</scrap>
+
+<p>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>.</p>
+
+<scrap>
+<head>Text</head>
+<prod id="NT-TextExpr">
+<lhs>TextExpr</lhs>
+<rhs>'text(' ')'</rhs>
+</prod>
+</scrap>
+
+<p>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>.</p>
+
+<issue id="issue-regex"><p>Should XSL support regular
+expressions for matching against any or all of pcdata content,
+attribute values, attribute names, element type names?</p></issue>
+
+
+<scrap>
+<head>Comments</head>
+<prod id="NT-CommentExpr">
+<lhs>CommentExpr</lhs>
+<rhs>'comment(' ')'</rhs>
+</prod>
+</scrap>
+
+<p>The result is the set of all comment nodes which are children of
+the context of the <nt def="NT-CommentExpr">CommentExpr</nt>.</p>
+
+<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>
+
+<p>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:</p>
+
+<ulist>
+
+<item><p>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.</p></item>
+
+<item><p>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.</p></item>
+
+</ulist>
+
+<p>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.</p>
+
+<issue id="issue-class-attribute"><p>Should there be a way of
+specifying that an attribute serves as a class attribute and then
+pattern syntax that treats class attributes specially?</p></issue>
+
+<scrap>
+<head>Ancestors</head>
+<prod id="NT-AncestorExpr">
+<lhs>AncestorExpr</lhs>
+<rhs>'ancestor(' <nt def="NT-MatchExpr">MatchExpr</nt> ')'</rhs>
+</prod>
+</scrap>
+
+<p>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.</p>
+
+<scrap>
+<head>Identity</head>
+<prod id="NT-IdentityExpr">
+<lhs>IdentityExpr</lhs>
+<rhs>'.'</rhs>
+</prod>
+</scrap>
+
+<p>The result is the context of the <nt
+def="NT-IdentityExpr">IdentityExpr</nt>.</p>
+
+<scrap>
+<head>Parents</head>
+<prod id="NT-ParentExpr">
+<lhs>ParentExpr</lhs>
+<rhs>'..'</rhs>
+</prod>
+</scrap>
+
+<p>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.</p>
+
+<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>
+
+<p>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.</p>
+
+<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>
+
+<p>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.</p>
+
+<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>
+
+<p>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.</p>
+
+<scrap>
+<head>Grouping</head>
+<prod id="NT-BooleanGroupExpr">
+<lhs>BooleanGroupExpr</lhs>
+<rhs>'(' <nt def="NT-BooleanExpr">BooleanExpr</nt> ')'</rhs>
+</prod>
+</scrap>
+
+<p>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.</p>
+
+<scrap>
+<head>Negation</head>
+<prod id="NT-NotExpr">
+<lhs>NotExpr</lhs>
+<rhs>'not(' <nt def="NT-BooleanExpr">BooleanExpr</nt> ')'</rhs>
+</prod>
+</scrap>
+
+<p>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.</p>
+
+<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>
+
+<p>The context of the <nt def="NT-PositionalExpr">PositionalExpr</nt>
+is a single node.</p>
+
+<ulist>
+
+<item><p>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.</p></item>
+
+<item><p>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.</p></item>
+
+<item><p>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.</p></item>
+
+<item><p>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.</p></item>
+
+</ulist>
+
+<scrap>
+<head>Testing Existence</head>
+<prod id="NT-TestExpr">
+<lhs>TestExpr</lhs>
+<rhs><nt def="NT-SelectExpr">SelectExpr</nt></rhs>
+</prod>
+</scrap>
+
+<p>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.</p>
+
+<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>
+
+<p>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>.</p>
+
+<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>
+
+<p>The value of the <nt def="NT-Literal">Literal</nt> is the sequence
+of characters inside the <code>"</code> or <code>'</code>
+characters>.</p>
+
+<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="&XMLNames;#NT-QName">QName</xnt></rhs>
+<rhs>| <nt def="NT-Literal">Literal</nt></rhs>
+</prod>
+<prod id="NT-PatternWhitespace">
+<lhs>PatternWhitespace</lhs>
+<rhs><xnt href="&XMLRec;#NT-S">S</xnt></rhs>
+</prod>
+</scrap>
+
+<p>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>.</p>
+
+</div3>
+
+</div2>
+
+<div2>
+<head>Templates</head>
+
+<div3>
+<head>Overview</head>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<eg><![CDATA[<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"><p>Should there be an instruction
+that generates an error, like the <code>error</code> procedure in
+DSSSL?</p></issue>
+
+<issue id="issue-multiple-results"><p>Should it be possible to create
+multiple result trees?</p></issue>
+
+</div3>
+
+<div3>
+<head>Creating Elements and Attributes</head>
+
+<div4>
+<head>Literal Result Elements</head>
+
+<p>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>).</p>
+
+<p>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>).</p>
+
+<p>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:</p>
+
+<ulist>
+
+<item><p>the namespace URI in the expanded name of an literal
+result element in the stylesheet</p></item>
+
+<item><p>the namespace URI in the expanded name of an attribute
+specified on a literal result element in the stylesheet</p></item>
+
+<item><p>the value of a namespace node on a literal result element in
+the stylesheet</p></item>
+
+</ulist>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<note><p>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.</p></note>
+
+<p>For example, the stylesheet</p>
+
+<eg><![CDATA[<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>
+
+<p>will generate an XSL stylesheet from a document of the form:</p>
+
+<eg><![CDATA[<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>
+
+<p>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.</p>
+
+<p>The following example creates a named attribute set
+<code>title-style</code> and uses it in a template rule.</p>
+
+<eg><![CDATA[<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>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+</div4>
+
+<div4>
+<head>Creating Elements with <code>xsl:element</code></head>
+
+<p>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.</p>
+
+<p>The value of the <code>name</code> attribute after instantiation
+must have one of two forms:</p>
+
+<ulist>
+
+<item><p>It can be a <xnt href="&XMLNames;#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.</p></item>
+
+<item><p>It can be a namespace URI followed by a <code>#</code>
+character followed by an <xnt
+href="&XMLNames;#NT-NCName">NCName</xnt>. This can be used
+conjunction with a <nt def="NT-NameExpr">NameExpr</nt> to compute a
+qualified name.</p></item>
+
+</ulist>
+
+</div4>
+
+<div4>
+<head>Creating Attributes with <code>xsl:attribute</code></head>
+
+<p>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.</p>
+
+<p>The following are all errors:</p>
+
+<ulist>
+
+<item><p>Adding an attribute to an element after children have been
+added to it; implementations may either signal the error or ignore the
+attribute.</p></item>
+
+<item><p>Including nodes other than text nodes in the value of an
+attribute; implementations may either signal the error or ignore the
+added nodes.</p></item>
+
+<item><p>Adding an attribute that has the same name as an attribute
+already added; implementations may either signal the error or ignore
+the duplicate attribute.</p></item>
+
+<item><p>Adding an attribute to a node that is not an element;
+implementations may either signal the error or ignore the
+attribute.</p></item>
+
+</ulist>
+
+</div4>
+
+</div3>
+
+<div3>
+
+<head>Creating Text</head>
+
+<p>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.</p>
+
+<p>Note that text is processed at the tree level. Thus, markup of
+<code>&amp;lt;</code> in a template will be represented in the
+stylesheet tree by a text node that includes the character
+<code>&lt;</code>. This will create a text node in the result tree
+that contains a <code>&lt;</code> character, which will be represented
+by the markup <code>&amp;lt;</code> (or an equivalent character
+reference) when the result tree is externalized as an XML
+document.</p>
+
+<p>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.</p>
+
+</div3>
+
+
+<div3>
+<head>Creating Processing Instructions</head>
+
+<p>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>.</p>
+
+<p>For example, this</p>
+
+<eg><![CDATA[<xsl:pi name="xml-stylesheet">href="book.css" type="text/css"</xsl:pi>]]></eg>
+
+<p>would create the processing instruction</p>
+
+<eg><![CDATA[<?xml-stylesheet href="book.css" type="text/css"?>]]></eg>
+
+<p>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.</p>
+
+<p>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>.</p>
+
+</div3>
+
+<div3>
+<head>Creating Comments</head>
+
+<p>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.</p>
+
+<p>For example, this</p>
+
+<eg><![CDATA[<xsl:comment>This file is automatically generated. Do not edit!</xsl:comment>]]></eg>
+
+<p>would create the comment</p>
+
+<eg><![CDATA[<!--This file is automatically generated. Do not edit!-->]]></eg>
+
+<p>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.</p>
+
+<p>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>.</p>
+
+</div3>
+
+<div3>
+<head id="children">Processing with Template Rules</head>
+
+<p>This example creates a block for a <code>chapter</code>
+element and then processes its immediate children.</p>
+
+<eg><![CDATA[<xsl:template match="chapter">
+ <fo:block>
+ <xsl:apply-templates/>
+ </fo:block>
+</xsl:template>]]></eg>
+
+<p>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.</p>
+
+<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>
+
+<p>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>:</p>
+
+<eg><![CDATA[<xsl:template match="author-group">
+ <fo:sequence>
+ <xsl:apply-templates select="author"/>
+ </fo:sequence>
+</xsl:template>]]></eg>
+
+<p>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>:</p>
+
+<eg><![CDATA[<xsl:template match="author-group">
+ <fo:sequence>
+ <xsl:apply-templates select="author/first-name"/>
+ </fo:sequence>
+</xsl:template>]]></eg>
+
+<p><code>//</code> can be used in the pattern to allow the matches to
+occur at arbitrary depths.</p>
+
+<p>This example processes all of the <code>heading</code> elements
+contained in the <code>book</code> element.</p>
+
+<eg><![CDATA[<xsl:template match="book">
+ <fo:block>
+ <xsl:apply-templates select=".//heading"/>
+ </fo:block>
+</xsl:template>]]></eg>
+
+<p>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>.</p>
+
+<eg><![CDATA[<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>
+
+<p>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.</p>
+
+<p>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>:</p>
+
+<eg><![CDATA[<xsl:template match="id(cfo)">
+ <xsl:apply-templates select="name"/> reports to <xsl:apply-templates select="id(ceo)/name"/>
+</xsl:template>]]></eg>
+
+<p>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.</p>
+
+<eg><![CDATA[<xsl:template match="product">
+ <TABLE>
+ <xsl:apply-templates select="sales/domestic"/>
+ </TABLE>
+ <TABLE>
+ <xsl:apply-templates select="sales/foreign"/>
+ </TABLE>
+</xsl:template>]]></eg>
+
+<note>
+
+<p>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</p>
+
+<eg><![CDATA[<doc><div><div></div></div></doc>]]></eg>
+
+<p>the rule</p>
+
+<eg><![CDATA[<xsl:template match="doc">
+ <xsl:apply-templates select=".//div"/>
+</xsl:template>]]></eg>
+
+<p>will process both the outer <code>div</code> and inner <code>div</code>
+elements.</p>
+
+</note>
+
+<p>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.</p>
+
+<issue id="issue-select-function"><p>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?</p></issue>
+
+</div3>
+
+<div3>
+
+<head>Direct Processing</head>
+
+<p>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.</p>
+
+<ednote><edtext>Make it clear that it changes the current
+node.</edtext></ednote>
+
+<p>For example, given an XML document with this structure</p>
+
+<eg><![CDATA[<customers>
+ <customer>
+ <name>...</name>
+ <order>...</order>
+ <order>...</order>
+ </customer>
+ <customer>
+ <name>...</name>
+ <order>...</order>
+ <order>...</order>
+ </customer>
+</customers>]]></eg>
+
+<p>the following would create an HTML document containing a table with
+a row for each <code>customer</code> element</p>
+
+<eg><![CDATA[<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>
+
+<p>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.</p>
+
+</div3>
+
+<div3>
+<head>Processing Modes</head>
+
+<p>Processing modes allow an element to processed multiple times, each
+time producing a different result.</p>
+
+<p>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.</p>
+
+<p>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>.</p>
+
+<ednote><edtext>Add some examples.</edtext></ednote>
+
+</div3>
+
+<div3>
+<head>Sorting</head>
+
+<p>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.</p>
+
+<p><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).</p>
+
+<p>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:</p>
+
+<ulist>
+
+<item><p><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></p></item>
+
+<item><p><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</p></item>
+
+<item><p><code>data-type</code> specifies the data type of the
+strings; the following values are allowed</p>
+
+<ulist>
+
+<item><p><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></p></item>
+
+<item><p><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</p></item>
+
+</ulist>
+
+<p>The default value is <code>text</code>.</p>
+
+<ednote><edtext>We plan to leverage the work on XML schemas to define
+further values in the future.</edtext></ednote>
+
+</item>
+
+<item><p><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.</p></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>
+
+<p>The values of all of the above attributes are interpreted as
+<termref def="dt-attribute-value-template">attribute value
+templates</termref>.</p>
+
+<note><p>It is recommended that implementors consult <bibref
+ref="UNICODE-TR10"/> for information on internationalized
+sorting.</p></note>
+
+<p>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.</p>
+
+<p>For example, suppose an employee database has the form</p>
+
+<eg><![CDATA[<employees>
+ <employee>
+ <name>
+ <first>James</first>
+ <last>Clark</last>
+ </name>
+ ...
+ </employee>
+</employees>
+]]></eg>
+
+<p>Then a list of employees sorted by name could be generated
+using:</p>
+
+<eg><![CDATA[<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>
+
+<p>The <code>xsl:number</code> element does numbering based on the
+position of the current node in the source tree.</p>
+
+<p>The <code>xsl:number</code> element can have the following
+attributes:</p>
+
+<ulist>
+
+<item><p>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>.</p></item>
+
+<item><p>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.</p></item>
+
+<item><p>The <code>from</code> attribute is a <termref
+def="dt-match-pattern">match pattern</termref> that specifies where
+counting starts from.</p></item>
+
+</ulist>
+
+<p>In addition the <code>xsl:number</code> element has the attributes
+specified in <specref ref="convert"/> for number to string
+conversion.</p>
+
+<p>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:</p>
+
+<ulist>
+
+<item><p>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.</p></item>
+
+<item><p>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.</p></item>
+
+<item><p>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.</p></item>
+
+</ulist>
+
+<p>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.</p>
+
+<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>
+
+<p>The following would number the items in an ordered list:</p>
+
+<eg><![CDATA[<xsl:template match="ol/item">
+ <fo:block>
+ <xsl:number/><xsl:text>. </xsl:text><xsl:apply-templates/>
+ </fo:block>
+<xsl:template>]]></eg>
+
+<p>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.</p>
+
+<eg><![CDATA[<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>
+
+<p>The following example numbers notes sequentially within a
+chapter:</p>
+
+<eg><![CDATA[<xsl:template match="note">
+ <fo:block>
+ <xsl:number level="any" from="chapter" format="(1) "/>
+ <xsl:apply-templates/>
+ </fo:block>
+</xsl:template>]]></eg>
+
+<p>The following example would number <code>H4</code> elements in HTML
+with a three-part label:</p>
+
+<eg><![CDATA[<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>
+
+<p>The root node of the result and each result element has a set of
+named counters (a mapping from names to integers).</p>
+
+<p>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>.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<note><p>The numbering may be performed in the tree construction
+process or may be left for the formatting process.</p></note>
+
+<note><p>These facilities for result tree numbering are based on the
+facilities for automatic numbering in <bibref ref="CSS2"/>.</p></note>
+
+<p>The following example would number notes sequentially throughout a
+document:</p>
+
+<eg><![CDATA[<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>
+
+<p>The following would turn ordered lists into definition lists:</p>
+
+<eg><![CDATA[<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>
+
+<p>The following would do HTML style numbering:</p>
+
+<eg><![CDATA[<xsl:template match="h2">
+ <xsl:counter-increment name="h2"/>
+ <p>
+ <xsl:counter name="h2"/>
+ <xsl:text>. </xsl:text>
+ <xsl:apply-templates/>
+ </p>
+ <xsl:counter-reset name="h3"/>
+</xsl:template>
+
+<xsl:template match="h3">
+ <xsl:counter-increment name="h3"/>
+ <p>
+ <xsl:counter name="h2"/>
+ <xsl:text>.</xsl:text>
+ <xsl:counter name="h3"/>
+ <xsl:text>. </xsl:text>
+ <xsl:apply-templates/>
+ </p>
+ <xsl:counter-reset name="h4"/>
+</xsl:template>
+
+<xsl:template match="h4">
+ <xsl:counter-increment name="h4"/>
+ <p>
+ <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/>
+ </p>
+</xsl:template>]]></eg>
+
+<p>The following would deal with recursive divs each with a title child:</p>
+
+<eg><![CDATA[<xsl:template match="div">
+ <div>
+ <xsl:apply-templates/>
+ </div>
+</xsl:template>
+
+<xsl:template match="title">
+ <p>
+ <xsl:counter-increment name="div"/>
+ <xsl:counters name="div" format="1.1. "/>
+ <xsl:apply-templates/>
+ </p>
+ <xsl:counter-reset name="div"/>
+</xsl:template>]]></eg>
+
+</div4>
+
+<div4 id="convert">
+<head>Number to String Conversion Attributes</head>
+
+<p>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.</p>
+
+<p>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>.</p>
+
+<p>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:</p>
+
+<ulist>
+
+<item><p>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>.</p></item>
+
+<item><p>A format token <code>A</code> generates the sequence <code>A
+B C ... Z AA AB AC...</code>.</p></item>
+
+<item><p>A format token <code>a</code> generates the sequence <code>a
+b c ... z aa ab ac...</code>.</p></item>
+
+<item><p>A format token <code>i</code> generates the sequence <code>i
+ii iii iv v vi vii vii ix x ...</code>.</p></item>
+
+<item><p>A format token <code>I</code> generates the sequence <code>I
+II III IV V VI VII VII IX X ...</code>.</p></item>
+
+<item><p>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>.</p></item>
+
+</ulist>
+
+<p>When numbering with an alphabetic sequence, the
+<code>xml:lang</code> attribute specifies which language's alphabet is
+to be used.</p>
+
+<note><p>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>.</p></note>
+
+<p>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.</p>
+
+<p>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>.</p>
+
+<p>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.</p>
+
+<ednote><edtext>Specify what should happen when the sequence runs
+out.</edtext></ednote>
+
+<p>Here are some examples of conversion specifications:</p>
+
+<ulist>
+
+<item><p><code>format="&amp;#x30A2;"</code> specifies Katakana
+numbering</p></item>
+
+<item><p><code>format="&amp;#x30A4;"</code> specifies Katakana
+numbering in the <quote>iroha</quote> order</p></item>
+
+<item><p><code>format="&amp;#x0E51;"</code> specifies numbering with
+Thai digits</p></item>
+
+<item><p><code>format="&amp;#x05D0;" letter-value="other"</code>
+specifies <quote>traditional</quote> Hebrew numbering</p></item>
+
+<item><p><code>format="&amp;#x10D0;" letter-value="other"</code>
+specifies Georgian numbering</p></item>
+
+<item><p><code>format="&amp;#x03B1;" letter-value="other"</code>
+specifies <quote>classical</quote> Greek numbering</p></item>
+
+<item><p><code>format="&amp;#x0430;" letter-value="other"</code>
+specifies Old Slavic numbering</p></item>
+
+</ulist>
+
+</div4>
+
+</div3>
+
+<div3>
+<head>Conditionals within a Template</head>
+
+<p>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.</p>
+
+<div4>
+<head>Conditional Processing with <code>xsl:if</code></head>
+
+<p>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:</p>
+
+<eg><![CDATA[<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>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<eg><![CDATA[<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>
+
+<p>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).</p>
+
+<p>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.</p>
+
+<p>For example, the identity transformation can be written using
+<code>xsl:copy</code>:</p>
+
+<eg><![CDATA[<xsl:template match="*|comment()|pi()">
+ <xsl:copy>
+ <xsl:apply-templates/>
+ </xsl:copy>
+</xsl:template>]]></eg>
+
+<issue id="issue-copy-attributes"><p>Should there be some way for
+<code>xsl:copy</code> to control the copying of
+attributes?</p></issue>
+
+</div3>
+
+
+<div3 id="stringexpr">
+<head>Computing Generated Text</head>
+
+<p>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>).</p>
+
+<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>
+
+<p>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>.</p>
+
+<issue id="issue-resolve-expr"><p>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?</p></issue>
+
+<scrap>
+<head>Name Expression</head>
+<prod id="NT-NameExpr">
+<lhs>NameExpr</lhs>
+<rhs>'name' '(' <nt def="NT-SelectExpr">SelectExpr</nt> ')'</rhs>
+</prod>
+</scrap>
+
+<p>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.</p>
+
+</div4>
+
+<div4>
+<head>Using String Expressions with <code>xsl:value-of</code></head>
+
+<p>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.</p>
+
+<p>For example, the following creates an HTML paragraph from a
+<code>person</code> element with <code>first-name</code> and
+<code>surname</code> attributes.</p>
+
+<eg><![CDATA[<xsl:template match="person">
+ <P>
+ <xsl:value-of select="@first-name"/>
+ <xsl:text> </xsl:text>
+ <xsl:value-of select="@surname"/>
+ </P>
+</xsl:template>]]></eg>
+
+<p>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.</p>
+
+<eg><![CDATA[<xsl:template match="person">
+ <P>
+ <xsl:value-of select="first-name"/>
+ <xsl:text> </xsl:text>
+ <xsl:value-of select="surname"/>
+ </P>
+</xsl:template>]]></eg>
+
+<p>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.</p>
+
+<eg><![CDATA[<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"><p>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>.</p></issue>
+
+</div4>
+
+<div4 id="attribute-value-templates">
+<head>Attribute Value Templates</head>
+
+<p><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.</p>
+
+<p>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:</p>
+
+<eg><![CDATA[<xsl:constant name="image-dir" value="/images"/>
+
+<xsl:template match="photograph">
+<IMG SRC="{constant(image-dir)}/{href}" WIDTH="{size/@width}"/>
+</xsl:template>]]></eg>
+
+<p>With this source</p>
+
+<eg><![CDATA[<photograph>
+ <href>headquarters.jpg</href>
+ <size width="300"/>
+</photograph>]]></eg>
+
+<p>the result would be</p>
+
+<eg><![CDATA[<IMG SRC="/images/headquarters.jpg" WIDTH="300"/>]]></eg>
+
+<p>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.</p>
+
+<p>Curly braces are <emph>not</emph> recognized recursively inside
+string expressions. For example:</p>
+
+<eg role="error"><![CDATA[<a href="#{id({@ref})/title}">]]></eg>
+
+<p>is <emph>not</emph> allowed. Instead use simply:</p>
+
+<eg><![CDATA[<a href="#{id(@ref)/title}">]]></eg>
+
+</div4>
+
+</div3>
+
+<div3>
+<head>String Constants</head>
+
+<p>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.</p>
+
+<p>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>.</p>
+
+<p>String constants are referenced using a <nt
+def="NT-ConstantRef">ConstantRef</nt> string expression.</p>
+
+<scrap>
+<head>String Constant References</head>
+<prod id="NT-ConstantRef">
+<lhs>ConstantRef</lhs>
+<rhs>'constant' '(' <xnt href="&XMLNames;#NT-NCName">NCName</xnt> ')'</rhs>
+</prod>
+</scrap>
+
+<eg><![CDATA[<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"><p>Should there be a way to define
+local constants?</p></issue>
+
+<p>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.</p>
+
+</div3>
+
+<div3>
+<head>Macros</head>
+
+<issue id="issue-macro-name"><p>Should macros be called something
+else?</p></issue>
+
+<p>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.</p>
+
+<eg><![CDATA[<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>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<scrap>
+<head>Macro Argument References</head>
+<prod id="NT-MacroArgRef">
+<lhs>MacroArgRef</lhs>
+<rhs>'arg' '(' <xnt href="&XMLNames;#NT-NCName">NCName</xnt> ')'</rhs>
+</prod>
+</scrap>
+
+<p>This example defines a macro for a <code>numbered-block</code> with
+an argument to control the format of the number.</p>
+
+<eg><![CDATA[<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>
+
+<p>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.</p>
+
+<issue id="issue-macro-arg-syntax"><p>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?</p></issue>
+
+</div3>
+</div2>
+
+<div2>
+<head>Combining Stylesheets</head>
+
+<p>XSL provides two mechanisms to combine stylesheets:</p>
+
+<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>
+
+<p>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"/>).</p>
+
+<eg><![CDATA[<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>
+
+<p><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></p>
+
+<p>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.</p>
+
+<issue id="issue-stylesheet-partition"><p>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?</p></issue>
+
+<issue id="issue-import-source"><p>Provide a way for a stylesheet
+to import a stylesheet that is embedded in the document.</p></issue>
+
+<issue id="issue-import-media"><p>Should we provide media-dependent
+imports as in CSS?</p></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>
+
+<p><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.</p>
+
+<ednote><edtext>Expand this.</edtext></ednote>
+
+</div3>
+
+<div3>
+<head>Stylesheet Inclusion</head>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<ednote><edtext>What happens when a stylesheet directly or indirectly
+includes itself?</edtext></ednote>
+
+</div3>
+
+<div3>
+<head>Embedding Stylesheets</head>
+
+<p>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:</p>
+
+<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>
+
+<p>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:</p>
+
+<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>
+<p>It is not in the scope of XSL to define such a mechanism.</p>
+<note>
+<p>This is because the mechanism should be independent of any one stylesheet
+mechanism.</p>
+</note>
+<p>The xsl:stylesheet element may have an ID attribute that specifies a unique
+identifier.</p>
+
+<note><p>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.</p></note>
+
+<p>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.</p>
+
+<eg><![CDATA[<?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><p>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.</p></note>
+
+</div3>
+</div2>
+
+<div2>
+<head>Extensibility</head>
+
+<p>This section will describe an extensibility mechanism for the tree
+construction process.</p>
+
+<issue id="issue-construct-extensibility"><p>Should there be some
+extensibility mechanism for the tree construction process? If so, how
+should it work? Should it be language independent?</p></issue>
+
+</div2>
+
+</div1>
+
+&fo;
+
+</body>
+<back>
+<div1>
+<head>DTD for XSL Stylesheets</head>
+
+<p>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:</p>
+
+<eg><![CDATA[<!ENTITY % result-elements "
+ | fo:sequence
+ | fo:block
+">]]></eg>
+
+<eg><![CDATA[<!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;
+>
+
+<!-- Used for attribute values that are URIs.-->
+<!ENTITY % URI "CDATA">
+
+<!-- Used for attribute values that are patterns.-->
+<!ENTITY % pattern "CDATA">
+
+<!-- Used for attribute values that are a priority. -->
+<!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>
+
+<!-- xsl:sort cannot occur after any other elements or
+any non-whitespace character -->
+
+<!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
+>
+
+<!-- xsl:macro-arg cannot occur after any other elements or
+any non-whitespace character -->
+
+<!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
+>
+
+<!-- This is allowed only within xsl:macro -->
+<!ELEMENT xsl:contents EMPTY>
+
+<!-- xsl:arg cannot occur after any other elements or
+any non-whitespace character -->
+
+<!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>
+<p>The following is a simple but complete stylesheet.</p>
+
+<eg><![CDATA[<?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>
+
+<p>With the following source document</p>
+
+<eg><![CDATA[<doc>
+<title>An example</title>
+<p>This is a test.</p>
+<p>This is <emph>another</emph> test.</p>
+</doc>]]></eg>
+
+<p>it would produce the following result</p>
+
+<eg><![CDATA[<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>
+
+<p>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:</p>
+
+<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>
+<p>The following have contributed to authoring this draft:</p>
+<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 &amp; 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>
+
+<p><code>xsl:process</code> and <code>xsl:process-children</code> have
+been combined into <code>xsl:apply-templates.</code></p>
+
+<p>The <code>expr</code> attribute of <code>xsl:value-of</code> has
+been renamed to <code>select</code>.</p>
+
+<p>Support for comments has been added.</p>
+
+<p>Support for processing instructions has been added.</p>
+
+<p>Support for text nodes has been added.</p>
+
+<p>Support for result tree numbering has been added.</p>
+
+<p>Support for sorting has been added.</p>
+
+<p>The <code>xsl:copy</code> element has been added.</p>
+
+<p>The <code>xsl:element</code> element has been added.</p>
+
+<p>The <code>xsl:attribute</code> element has been added.</p>
+
+<p>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.</p>
+
+<p>The argument to id() must now be quoted. Select patterns can also
+be used as an argument.</p>
+
+<p>The syntax for patterns has been reworked; it is now more general
+than before.</p>
+
+<p>The syntax for quoting namespaces has been changed.</p>
+
+<p>Specificity has been removed.</p>
+
+<p>Priorities can be real numbers.</p>
+
+<p>Support for processing modes has been added.</p>
+
+<p><code>xsl:apply-imports</code> has been added.</p>
+
+<p><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.</p>
+
+<p>The default namespace (as declared with the <code>xmlns</code>
+attribute) is not used for element type names in patterns.</p>
+
+</inform-div1>
+</back>
+</spec>