diff options
Diffstat (limited to 'Master/texmf-dist/doc/latex/latex-web-companion/ch7/xsl.xml')
| -rw-r--r-- | Master/texmf-dist/doc/latex/latex-web-companion/ch7/xsl.xml | 3838 |
1 files changed, 3838 insertions, 0 deletions
diff --git a/Master/texmf-dist/doc/latex/latex-web-companion/ch7/xsl.xml b/Master/texmf-dist/doc/latex/latex-web-companion/ch7/xsl.xml new file mode 100644 index 00000000000..694a07a1c42 --- /dev/null +++ b/Master/texmf-dist/doc/latex/latex-web-companion/ch7/xsl.xml @@ -0,0 +1,3838 @@ +<?xml version="1.0" encoding="utf-8"?> +<?xml-stylesheet href="stylesheet/xml.dsl" type="text/dsssl"?> +<!-- $Id: xsl.xml 1.223 1998/12/02 10:12:01 jjc Exp $ --> +<!DOCTYPE spec SYSTEM "xslspec.dtd" [ +<!ENTITY XMLRec "http://www.w3.org/TR/REC-xml"> +<!ENTITY XMLNames "http://www.w3.org/TR/WD-xml-names"> +<!ENTITY year "1998"> +<!ENTITY month "December"> +<!ENTITY day "2"> +<!ENTITY MMDD "1202"> +<!ENTITY fo SYSTEM "fo.xml"> +<!ENTITY D "DSSSL:"> +<!ENTITY C "CSS:"> +]> +<spec> +<header> +<title>Extensible Stylesheet Language (XSL)</title> +<version>Version 1.0</version> +<w3c-designation>WD-xsl-&year;&MMDD;</w3c-designation> +<w3c-doctype>World Wide Web Consortium Working Draft</w3c-doctype> +<pubdate><day>&day;</day><month>&month;</month><year>&year;</year></pubdate> +<publoc> +<loc href="http://www.w3.org/TR/&year;/WD-xsl-&year;&MMDD;" + >http://www.w3.org/TR/&year;/WD-xsl-&year;&MMDD;</loc> +<loc href="http://www.w3.org/TR/&year;/WD-xsl-&year;&MMDD;.xml" + >http://www.w3.org/TR/&year;/WD-xsl-&year;&MMDD;.xml</loc> +<loc href="http://www.w3.org/TR/&year;/WD-xsl-&year;&MMDD;.html" + >http://www.w3.org/TR/&year;/WD-xsl-&year;&MMDD;.html</loc> +<loc href="http://www.w3.org/TR/&year;/WD-xsl-&year;&MMDD;.pdf" + >http://www.w3.org/TR/&year;/WD-xsl-&year;&MMDD;.pdf</loc> +</publoc> +<latestloc> +<loc href="http://www.w3.org/TR/WD-xsl" + >http://www.w3.org/TR/WD-xsl</loc> +</latestloc> +<prevlocs> +<loc href="http://www.w3.org/TR/1998/WD-xsl-19980818" + >http://www.w3.org/TR/1998/WD-xsl-19980818</loc> +</prevlocs> +<authlist> +<author part="Tree Construction"> +<name>James Clark</name> +<email href="mailto:jjc@jclark.com">jjc@jclark.com</email> +</author> +<author part="Formatting Objects"> +<name>Stephen Deach</name> +<affiliation>Adobe</affiliation> +<email href="mailto:sdeach@adobe.com">sdeach@adobe.com</email> +</author> +</authlist> + +<status> + +<p>This is a W3C Working Draft for review by W3C members and other +interested parties. This adds additional functionality to what was +described in the the previous draft, however the basic of the previous +draft remains unchanged. It is a draft document and may be updated, +replaced, or obsoleted by other documents at any time. The XSL +Working Group will not allow early implementation to constrain its +ability to make changes to this specification prior to final release. +It is inappropriate to use W3C Working Drafts as reference material or +to cite them as other than <quote>work in progress</quote>. A list of +current W3C working drafts can be found at <loc +href="http://www.w3.org/TR">http://www.w3.org/TR</loc>.</p> + +<p>Comments may be sent to <loc +href="mailto:xsl-editors@w3.org">xsl-editors@w3.org</loc>. Public +discussion of XSL takes place on the <loc +href="http://www.mulberrytech.com/xsl/xsl-list/index.html">XSL-List</loc> +mailing list.</p> + +</status> + +<abstract> + +<p>XSL is a language for expressing stylesheets. It consists of two +parts:</p> + +<olist> + +<item><p>a language for transforming XML documents, and</p></item> + +<item><p>an XML vocabulary for specifying formatting +semantics.</p></item> + +</olist> + +<p>An XSL stylesheet specifies the presentation of a class of XML +documents by describing how an instance of the class is transformed +into an XML document that uses the formatting vocabulary.</p> + +</abstract> + +<langusage> +<language id="EN">English</language> +<language id="ebnf">EBNF</language> +</langusage> +<revisiondesc> +<slist> +<sitem>See RCS log for revision history.</sitem> +</slist> +</revisiondesc> +</header> +<body> +<div1> +<head>Overview</head> + +<p>XSL is a language for expressing stylesheets. Each stylesheet +describes rules for presenting a class of XML source documents. There +are two parts to the presentation process. First, the result tree is +constructed from the source tree. Second, the result tree is +interpreted to produce formatted output on a display, on paper, in +speech or onto other media.</p> + +<p>The first part, constructing the result tree, is achieved by +associating patterns with templates. A pattern is matched against +elements in the source tree. A template is instantiated to create +part of the result tree. The result tree is separate from the source +tree. The structure of the result tree can be completely different +from the structure of the source tree. In constructing the result +tree, the source tree can be filtered and reordered, and arbitrary +structure can be added.</p> + +<p>The second part, formatting, is achieved by using the formatting +vocabulary specified in this document to construct the result tree. +Formally, this vocabulary is an XML namespace. Each element type in the +vocabulary corresponds to a formatting object class. A formatting +object class represents a particular kind of formatting behavior. For +example, the block formatting object class represents the breaking of +the content of a paragraph into lines. Each attribute in the +vocabulary corresponds to a formatting property. A formatting object +class has a specific set of formatting properties which provide finer +control over the behavior of the formatting object class; for example, +controlling indenting of lines, spacing between lines, and spacing +before and after the collection of lines. A formatting object can +have content, and its formatting behavior is applied to its +content.</p> + +<p>XSL does not require result trees to use the formatting vocabulary +and thus can be used for general XML transformations. For example, +XSL can be used to transform XML to <quote>well-formed</quote> HTML, +that is, XML that uses the element types and attributes defined by +HTML.</p> + +<p>When the result tree uses the formatting vocabulary, a conforming +XSL implementation must be able to interpret the result tree according +to the semantics of the formatting vocabulary as defined in this +document; it may also be able to externalize the result tree as XML, +but it is not required to be able to do so.</p> + +<p>This document does not specify how a stylesheet is associated with +an XML document. It is recommended that XSL processors support the +mechanism described in <bibref ref="XMLSTYLE"/>.</p> + +</div1> + +<div1> +<head>Tree Construction</head> + +<div2> +<head>Overview</head> + +<p>A stylesheet contains a set of template rules. A +template rule has two parts: a pattern which is matched against nodes +in the source tree and a template which can be instantiated +to form part of the result tree. This allows a stylesheet to be applicable to +a wide class of documents that have similar source tree +structures.</p> + +<p>A template is instantiated for a particular source element +to create part of the result tree. A template can contain elements +that specify literal result element structure. A template can also +contain elements that are instructions for creating result tree +fragments. When a template is instantiated, each instruction is +executed and replaced by the result tree fragment that it creates. +Instructions can select and process descendant elements. Processing a +descendant element creates a result tree fragment by finding the +applicable template rule and instantiating its template. Note +that elements are only processed when they have been selected by the +execution of an instruction. The result tree is constructed by +finding the template rule for the root node and instantiating +its template.</p> + +<p>In the process of finding the applicable template rule, more +than one template rule may have a pattern that matches a given +element. However, only one template rule will be applied. The +method for deciding which template rule to apply is described +in <specref ref="conflict"/>.</p> + +<p>XSL uses XML namespaces <bibref ref="XMLNAMES"/> to distinguish +elements that are instructions to the XSL processor from elements that +specify literal result tree structure. Instruction elements all +belong to the XSL namespace. The examples in this document use a +prefix of <code>xsl:</code> for elements in the XSL namespace.</p> + +<p>An XSL stylesheet contains an <code>xsl:stylesheet</code> document +element. This element may contain <code>xsl:template</code> elements +specifying template rules, which will be described later in +this document.</p> + +<p>The following is an example of a simple XSL stylesheet that +constructs a result tree for a sequence of <code>para</code> elements. +The <code>result-ns="fo"</code> attribute indicates that a tree using +the formatting object vocabulary is being constructed. The rule for +the root node specifies the use of a page sequence formatted with any +font with serifs. The <code>para</code> elements become +<code>block</code> formatting objects which are set in 10 point type +with a 12 point space before each block.</p> + +<eg><![CDATA[<xsl:stylesheet + xmlns:xsl="http://www.w3.org/TR/WD-xsl" + xmlns:fo="http://www.w3.org/TR/WD-xsl/FO" + result-ns="fo"> + <xsl:template match="/"> + <fo:page-sequence font-family="serif"> + <xsl:apply-templates/> + </fo:page-sequence> + </xsl:template> + + <xsl:template match="para"> + <fo:block font-size="10pt" space-before="12pt"> + <xsl:apply-templates/> + </fo:block> + </xsl:template> +</xsl:stylesheet>]]></eg> + +<p>The <code>xsl:stylesheet</code> element can also contain elements +importing other XSL stylesheets, elements defining macros, elements +defining global constants, and elements identifying source attributes +as individual element identifiers.</p> + +</div2> + +<div2> +<head>Stylesheet Structure</head> + +<p>A stylesheet is represented by an <code>xsl:stylesheet</code> +element in an XML document.</p> + +<p>XSL processors must use the XML namespaces mechanism <bibref +ref="XMLNAMES"/> for both source documents and stylesheets. All XSL +defined elements, that is those specified in this document with a +prefix of <code>xsl:</code>, will only be recognized by the XSL +processor if they belong to a namespace with the URI +<code>http://www.w3.org/TR/WD-xsl</code>; XSL defined elements are +recognized only in the stylesheet not in the source document.</p> + +<issue id="issue-versioning"><p>Should there be some way for a +stylesheet to indicate which version of XSL it conforms to? Can this +be done through the URI of the XSL namespace?</p></issue> + +<p>The <code>xsl:stylesheet</code> element has an optional +<code>result-ns</code> attribute; the value must be a namespace +prefix. If this attribute is specified, all result elements must +belong to the namespace identified by this prefix (the <term>result +namespace</term>). If there is a namespace declared as the default +namespace, then an empty string may be used as the value to specify +that the default namespace is the result namespace. If the +<code>result-ns</code> attribute specifies the XSL Formatting Objects +namespace, then in addition to constructing the result XML tree, the +XSL processor must interpret it according to the semantics defined in +this document. The XSL Formatting Objects namespace has the URI +<code>http://www.w3.org/TR/WD-xsl/FO</code>. The examples in this +document use the <code>fo:</code> prefix for this namespace.</p> + +<note><p>If an implementation wishes to use something in the result +tree or stylesheet to control the output of a non-XML representation +of the result tree, it should use the result namespace. In +particular, if it wishes to make use of something in the result tree +or stylesheet to indicate that the result tree should be output as +HTML that conforms to the HTML 4.0 Recommendation rather than as XML, +it should use a result namespace of +<code>http://www.w3.org/TR/REC-html40</code>; for example,</p> + +<eg><![CDATA[ +<xsl:stylesheet + xmlns:xsl="http://www.w3.org/TR/WD-xsl" + xmlns="http://www.w3.org/TR/REC-html40" + result-ns=""> + +<xsl:template match="/"> + <html> + <xsl:apply-templates/> + </html> +</xsl:template> + +... + +</xsl:stylesheet>]]></eg> +</note> + +<p>The <code>xsl:stylesheet</code> element may contain the following types +of elements:</p> +<olist> +<item><p><code>xsl:import</code></p></item> +<item><p><code>xsl:include</code></p></item> +<item><p><code>xsl:id</code></p></item> +<item><p><code>xsl:strip-space</code></p></item> +<item><p><code>xsl:preserve-space</code></p></item> +<item><p><code>xsl:macro</code></p></item> +<item><p><code>xsl:attribute-set</code></p></item> +<item><p><code>xsl:constant</code></p></item> +<item><p><code>xsl:template</code></p></item> +</olist> + +<p>This example shows the structure of a stylesheet. Ellipses +(<code>...</code>) indicate where attribute values or content have +been omitted. +Although this example shows one of each type of allowed element, +stylesheets may contain zero or more of each of these elements.</p> + +<eg><![CDATA[<?xml version="1.0"?> +<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl"> + <xsl:import href="..."/> + + <xsl:include href="..."/> + + <xsl:id attribute="..."/> + + <xsl:strip-space element="..."/> + + <xsl:preserve-space element="..."/> + + <xsl:macro name="..."> + ... + </xsl:macro> + + <xsl:attribute-set name="..."> + ... + </xsl:attribute-set> + + <xsl:constant name="..." value="..."/> + + <xsl:template match="..."> + ... + </xsl:template> +</xsl:stylesheet>]]></eg> + +<p>The order in which the children of the <code>xsl:stylesheet</code> +element occur is not significant except for <code>xsl:import</code> +elements and for error recovery. Users are free to order the elements +as they prefer, and stylesheet creation tools need not provide control +over the order in which the elements occur.</p> + +<issue id="issue-media-rule"><p>Should we provide the functionality +of CSS's <code>@media</code> rule and if so how?</p></issue> + +</div2> + +<div2> +<head>Processing Model</head> + +<ednote><edtext>This needs expanding and polishing.</edtext></ednote> + +<p>A node is processed to create a result tree fragment. The +result tree is constructed by processing the root node. A node is +processed by finding all the template rules with patterns that +match the node, and choosing the best amongst them. The chosen rule's +template is then instantiated for the node. <termdef +id="dt-current-node" term="Current Node">During the instantiation of +a template, the node for which the template is being +instantiated is called the current node.</termdef> A template +typically contains instructions that select an additional sequence of +source nodes for processing. A sequence of source nodes is processed +by appending the result tree structure created by processing each of +the members of the sequence in order. The process of matching, +instantiation and selection is continued recursively until no new +source nodes are selected for processing.</p> + +<p>Implementations are free to process the source document in any way +that produces the same result as if it were processed using this +processing model.</p> + +</div2> + +<div2 id="data-model"> +<head>Data Model</head> + +<p>XSL operates on an XML document, whether a stylesheet or a source +document, as a tree. Any two stylesheets or source documents that +have the same tree will be processed the same by XSL. The XML +document resulting from the tree construction process is also a tree. +This section describes how XSL models an XML document as a tree. This +model is conceptual only and does not mandate any particular +implementation.</p> + +<p>XML documents operated on by XSL must conform to the XML namespaces +specification <bibref ref="XMLNAMES"/>.</p> + +<p>The tree contains nodes. There are seven kinds of node:</p> + +<ulist> + +<item><p>root nodes</p></item> + +<item><p>element nodes</p></item> + +<item><p>text nodes</p></item> + +<item><p>attribute nodes</p></item> + +<item><p>namespace nodes</p></item> + +<item><p>processing instruction nodes</p></item> + +<item><p>comment nodes</p></item> + +</ulist> + +<p>Neither processing instruction nodes nor comment nodes are included +in the tree for the stylesheet.</p> + +<p>For every type of node there is a way of determing a string +<term>value</term> for a node of that type. For some types of node, +the value is part of the node; for other types of node, the value is +computed from the value of descendant nodes.</p> + +<issue id="issue-data-entity"><p>Should XSL provide support for +external data entities and notations?</p></issue> + +<div3 id="root-node"> +<head>Root Node</head> + +<p>The root node is the root of the tree. It does not occur anywhere +else in the tree. It has a single child which is the element node for +the document element of the document.</p> + +<p>The <term>value</term> of the root node is the value of the +document element.</p> + +</div3> + +<div3 id="element-nodes"> +<head>Element Nodes</head> + +<p>There is an element node for every element in the document. An +element has an expanded name consisting of a local name and a possibly +null URI (see <bibref ref="XMLNAMES"/>); the URI will be null if the +element type name has no prefix and there is no default namespace in +scope.</p> + +<p>The children of an element node are the element nodes and +characters for its content. Entity references to both internal and +external entities are expanded. Character references are +resolved.</p> + +<p><termdef id="dt-descendants" term="Descendants">The +<term>descendants</term> of an element node are the character +children, the element node children, and the descendants of the +element node children.</termdef></p> + +<p>The <term>value</term> of an element node is the string that +results from concatenating all characters that are <termref +def="dt-descendants">descendants</termref> of the element node in the +order in which they occur in the document.</p> + +<p><termdef id="dt-document-order" term="Document Order">The set of +all element nodes in a document can be ordered according to the order +of the start-tags of the elements in the document; this is known as +<term>document order</term>.</termdef></p> + +<div4 id="unique-id"> +<head>Unique IDs</head> + +<p>An element object may have a unique identifier (ID). This is the +value of the attribute which is declared in the DTD as type +<code>ID</code>. Since XSL must also work with XML documents that do +not have a DTD, stylesheets may specify which attributes in the source +document should be treated as IDs. The <code>xsl:id</code> element +has a required <code>attribute</code> attribute, which gives the name +of an attribute in the source document that should be treated as +specifying the element's ID. A stylesheet may contain more than one +<code>xsl:id</code> element, for cases where the source document uses +several attributes as IDs. An <code>xsl:id</code> element also has an +optional <code>element</code> attribute which specifies the name of an +element type; when the <code>element</code> attribute is specified, +then the <code>xsl:id</code> element specifies that the +<code>attribute</code> attribute of <code>element</code> elements are +treated as IDs. <code>xsl:id</code> elements may only occur in the +stylesheet body (not within a rule). The following causes XSL to +treat all <code>name</code> attributes in the source document as +IDs.</p> + +<eg><![CDATA[<xsl:id attribute="name"/>]]></eg> + +<p>It is an error if, as a consequence of the use of +<code>xsl:id</code>, there is more than one element with the same ID +in the source tree. An XSL processor may signal the error; if it does +not signal the error, it must recover by treating only the first (in +<termref def="dt-document-order">document order</termref>) of the +elements as having that ID.</p> + +<issue id="unique-id-content"><p>Should it be possible for a unique id +to be specified in the content of an element instead of in an +attribute?</p></issue> + +</div4> + +<div4 id="base-uri"> + +<head>Base URI</head> + +<p>An element node also has an associated URI called its base URI +which is used for resolving attribute values that represent relative +URIs into absolute URIs. If an element occurs in an external entity, +the base URI of that element is the URI of the external entity. +Otherwise the base URI is the base URI of the document.</p> + +</div4> + +</div3> + +<div3 id="attribute-nodes"> +<head>Attribute Nodes</head> + +<p>Each element node has an associated set of attribute nodes. A +defaulted attribute is treated the same as a specified attribute. If +an attribute was declared for the element type, but the default was +declared as <code>#IMPLIED</code>, and the attribute was not specified +on the element, then the element's attribute set does not contain a +node for the attribute.</p> + +<p>An attribute node has an expanded name and has a string value. The +expanded name consists of a local name and a possibly null URI (see +<bibref ref="XMLNAMES"/>); the URI will be null if the specified +attribute name did not have a prefix. The value is the normalized +value as specified by the XML Recommendation <bibref ref="XML"/>. An +attribute value whose value is of zero length is not treated +specially.</p> + +<p>There are no attribute nodes for attributes that declare namespaces +(see <bibref ref="XMLNAMES"/>).</p> + +<issue id="issue-external-dtd"><p>Should we specify something about +how we expect XSL processors to process external DTDs and parameter +entities? For example, what happens if an attribute default is +declared in an external DTD?</p></issue> + +</div3> + +<div3 id="namespace-nodes"> +<head>Namespace Nodes</head> + +<p>Each element has an associated set of namespace nodes, one for each +namespace prefix that is in scope for element and one for the default +namespace if one is in scope for the element. This means that an +element will have a namespace node:</p> + +<ulist> + +<item><p>for every attribute on the element whose name starts with +<code>xmlns:</code>;</p></item> + +<item><p>for every attribute on an ancestor element whose name starts +<code>xmlns:</code> unless the element itself or a nearer ancestor +redeclares the prefix;</p></item> + +<item> + +<p>for an <code>xmlns</code> attribute, unless its value is the empty +string.</p> + +<note><p>An attribute <code>xmlns=""</code> <quote>undeclares</quote> +the default namespace (see <bibref ref="XMLNAMES"/>).</p></note> + +</item> + +</ulist> + +<p>A namespace node has a name which is a string giving the prefix. +This is empty if the namespace node is for the default namespace. A +namespace node also has a value which is the namespace URI. If the +namespace declaration specifies a relative URI, then the resolved +absolute URI is used as the value.</p> + +<p>When writing an element node in the result tree out as XML, an XSL +processor must add sufficient namespace-declaring attributes to the +start-tag to ensure that if a tree were recreated from the XML, then +the set of namespace nodes on the element node in the recreated tree +would be equal to or a superset of the set of namespace nodes of the +element node in the result tree.</p> + +<note><p>The semantics of a document type may treat parts of attribute +values or data content as namespace prefixes. The presence of +namespace nodes ensures that the semantics can be preserved when the +tree is written out as XML.</p></note> + +</div3> + + +<div3> +<head>Processing Instruction Nodes</head> + +<p>There is a processing instruction node for every processing +instruction.</p> + +<ednote><edtext>What about processing instructions in the internal +subset or elsewhere in the DTD?</edtext></ednote> + +<p>An processing instruction has a name. This is a string equal to +the processing instruction's target. It also has a value. This is a +string equal to the part of the processing instruction following the +target and any whitespace. It does not include the terminating +<code>?></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><!--</code> or the closing +<code>--></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><![CDATA[<]]></code> in the source document will +treated the same as <code>&lt;</code>. Characters inside comments +or processing instructions are not character data. Line-endings in +external entities are normalized to #xA as specified in the XML +Recommendation <bibref ref="XML"/>.</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>&lt;</code> in a template will be represented in the +stylesheet tree by a text node that includes the character +<code><</code>. This will create a text node in the result tree +that contains a <code><</code> character, which will be represented +by the markup <code>&lt;</code> (or an equivalent character +reference) when the result tree is externalized as an XML +document.</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="&#x30A2;"</code> specifies Katakana +numbering</p></item> + +<item><p><code>format="&#x30A4;"</code> specifies Katakana +numbering in the <quote>iroha</quote> order</p></item> + +<item><p><code>format="&#x0E51;"</code> specifies numbering with +Thai digits</p></item> + +<item><p><code>format="&#x05D0;" letter-value="other"</code> +specifies <quote>traditional</quote> Hebrew numbering</p></item> + +<item><p><code>format="&#x10D0;" letter-value="other"</code> +specifies Georgian numbering</p></item> + +<item><p><code>format="&#x03B1;" letter-value="other"</code> +specifies <quote>classical</quote> Greek numbering</p></item> + +<item><p><code>format="&#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 & 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> |