<?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>
