WD-xslt11req-20000825 13.8 KB

Raw Blame History Permalink


<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<META http-equiv="Content-Type" content="text/html; charset=UTF-16">
<title>XSL Transformations Requirements</title>
<link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-WD">
<style type="text/css">p.element-syntax { border: solid thin }code { font-family: monospace }
.tabheader { background-color: #e0e0e0 }
.row0 { background-color: #f0f0f0 }
.row1 { background-color: white }
.java-class {
  font-family: monospace;
  border: 1px solid black;
  white-space: pre;
  color: black;
  background-color: #dfdfdf;
}
                </style>
</head>
<body>
<div class="head">
<a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/WWW/w3c_home" alt="W3C" height="48" width="72"></a>
<h1>XSL Transformations Requirements<br>Version 1.1</h1>
<h2>W3C  Working Draft 25 August 2000</h2>
<dl>
<dt>This version:</dt>
<dd>
<a href="http://www.w3.org/TR/2000/WD-xslt11req-20000825">http://www.w3.org/TR/2000/WD-xslt11req-20000825</a><br>
(available in <a href="http://www.w3.org/TR/2000/WD-xslt11req-20000825.xml">XML</a> or
<a href="http://www.w3.org/TR/2000/WD-xslt11req-20000825.html">HTML</a>)

</dd>
<dt>Latest version:</dt>
<dd><a href="http://www.w3.org/TR/xslt11req">http://www.w3.org/TR/xslt11req</a><br>

</dd>
<dt>Editor:</dt>
<dd>


Steve Muench
<a href="mailto:smuench@oracle.com">&lt;Steven.Muench@oracle.com&gt;</a>
<br>
</dd>
</dl>
<p class="copyright">
<a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">
Copyright</a> &copy;2000 <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>&reg;</sup> (<a href="http://www.lcs.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>, <a href="http://www.inria.fr/"><abbr lang="fr" title="Institut National de Recherche en Informatique et Automatique">INRIA</abbr></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>, <a href="http://www.w3.org/Consortium/Legal/copyright-documents-19990405">document use</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-software-19980720">software licensing</a> rules apply.</p>
<hr title="Separator for header">
</div>
<h2><a name="abstract">Abstract</a></h2>

<p>This document describes the requirements for the XSLT 1.1 specification.</p>

<h2><a name="status">Status of this document</a></h2>

<p>This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C. This document is the first public XSLT 1.1 Requirements working draft. </p>
<p>This is a W3C Working Draft for review by W3C Members and other interested parties. It is a draft document and may be updated, replaced or made obsolete by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". This is work in progress and does not imply endorsement by the <a href="http://www.w3.org/Consortium/Member/List">W3C membership</a>.</p>
<p>

This document has been produced as part of the <a href="http://www.w3.org/Style/Activity">W3C
Style activity</a>, following the procedures set out for the W3C Process. The document has been written by the <a href="http://www.w3.org/Style/XSL/Group">XSL Working Group</a> ( <a href="http://cgi.w3.org/MemberAccess/AccessRequest">W3C members only</a>). The goals of the XSL Working Group are discussed in the <a href="http://www.w3.org/Style/2000/xsl-charter.html">XSL Working Group charter</a>.

The XSL Working Group feels that the contents of this Working Draft are relatively stable, and therefore encourages feedback on this version.

</p>
<p>Comments on this document should be sent to the W3C mailing list <a href="mailto:xsl-editors@w3.org">xsl-editors@w3.org</a> (archived at <a href="http://lists.w3.org/Archives/Public/xsl-editors/">http://lists.w3.org/Archives/Public/xsl-editors/</a>).

A list of current W3C Recommendations and other technical documents can be found at <a href="http://www.w3.org/TR/">http://www.w3.org/TR/</a>.
</p>


<h2><a name="contents">Table of contents</a></h2>1 <a href="#section-Introduction">Introduction</a><br>2 <a href="#section-General-Requirements">General Requirements</a><br>3 <a href="#section-Requirements-for-Portable-Extension-Function-Implementations">Requirements for Portable Extension Function Implementations</a><br>4 <a href="#section-Requirements-for-Multiple-Output-Documents">Requirements for Multiple Output Documents</a><br>5 <a href="#section-Requirements-for-Result-Tree-Fragment-to-Node-set-Conversion">Requirements for Result Tree Fragment to Node-set Conversion</a><br>6 <a href="#section-Requirements-for-XML-Base-Support">Requirements for XML Base Support</a><br>7 <a href="#section-References">References</a><br>    7.1 <a href="#section-Normative-References">Normative References</a><br>
<hr>
<h2><a name="section-Introduction"></a>1 Introduction</h2>
<p> In addition to supporting user-defined extensions, numerous XSLT 1.0-compliant processors have exploited the XSLT 1.0 extension mechanism to provide additional <i>built-in</i> transformation functionality. As useful built-in extensions have emerged, users have embraced them and have begun to rely on them.
However the benefits of these extensions come at the price of portability. Since XSLT 1.0  (See <a href="#XSLT">[XSLT]</a>) provides no details or guidance on the <i>implementation</i> of extensions, today any user-written or built-in extensions are inevitably tied to a single XSLT processor. The XSLT user community has consistently voiced the opinion that the non-portability of stylesheets is a key problem.</p>
<p> The primary goal of the XSLT 1.1 specification is to improve stylesheet portability. This goal will be achieved by standardizing the mechanism for implementing extension functions, and by including into the core XSLT specification two of the built-in extensions that many existing vendors XSLT processors have added due to user demand: </p>
<ul>
<li>Support for multiple output documents from a transformation</li>
<li>Support for converting a result tree fragment to a nodeset for further processing</li>
</ul>
<p>By standardizing these extension-related aspects which multiple vendor implementations already provide, the ability to create stylesheets that work across multiple XSLT processors should improve dramatically. </p>
<p>A secondary goal of the XSLT 1.1 specification is to support the new XML Base (See <a href="#XMLBase">[XMLBase]</a>) specification.</p>
<p>This document provides the requirements that will achieve these goals.</p>


<blockquote>
<b>NOTE: </b>The working group has decided to limit the scope of XSLT 1.1 to the standardization of features already implemented in several XSLT 1.0 processors, and concentrate first on standardizing the implementation of extension <i>functions</i>. Standardization of extension elements and support for new XML Schema data type aware facilities are planned for  XSLT 2.0</blockquote>
<h2><a name="section-General-Requirements"></a>2 General Requirements</h2>
<p>Upward compatibility of XSLT stylesheets is an important criteria for existing users. To this end, we have the following requirements:</p>
<ul>
<li>Any stylesheet whose behaviour is fully specified in version 1.0, and which is not in error under version 1.0, MUST behave the same way under version 1.1.</li>
<li>If the XSLT 1.1 specification increments the <code>version</code> number to a number greater than <code>1.0</code>, it MUST clearly explain the rules for forward compatibility of <code>version="1.0"</code> stylesheets and the restrictions, if any, on the use of new features in stylesheets with <code>version="1.0"</code>.</li>
</ul>


<h2><a name="section-Requirements-for-Portable-Extension-Function-Implementations"></a>3 Requirements for Portable Extension Function Implementations</h2>
<p>XSLT 1.0 defines the facilities to unambiguously identify extension functions from built-in functions by requiring that extension functions be referenced using namespace-qualified names, e.g. <code>myprefix:myfunction()</code>. It provides the <code>function-available()</code> function to test for the availability of a particular function by name. The XSLT 1.1 specification will define the additional specifics necessary to enable the creation and use of extension functions across processors with the following requirements:</p>
<ul>
<li>Extension functions MUST work like built-in functions.</li>
<li>Language bindings MUST be provided for Java and ECMAScript</li>
<li>It MUST be <i>possible</i> to extend the mechanism naturally to support other languages in the future</li>
<li>A processor SHOULD NOT be <i>required</i> to implement the portable extension function binding for any particular language</li>
<li>A processor that implements extension functions for any language whose binding is provided by the XSLT specification MUST conform for those languages.</li>
<li>Extension function implementations MUST be allowed both inline as well as externally</li>
<li>It MUST be possible to pass arguments of all XPath datatypes to extension functions</li>
<li>It MUST be possible for extension functions to return all XPath datatypes as a result</li>
<li>Extension functions MUST be able to construct and return node-sets of XML fragments</li>
<li>It MUST be possible to include or import extension functions from another stylesheet </li>
<li>A processor SHOULD fail with error if selection of extension function implementation is ambiguous</li>
<li>A processor SHOULD convert arguments in a way consistent with the built-in functions</li>
<li>It SHOULD be possible to return an object of <i>any</i> host-language type from the extension function</li>
<li>It SHOULD be possible to pass an object of <i>any</i> host-language type to an extension function</li>
<li>It SHOULD be possible to support invoking overloaded functions in Java</li>
</ul>
<h2><a name="section-Requirements-for-Multiple-Output-Documents"></a>4 Requirements for Multiple Output Documents</h2>
<p>Using the <code>document()</code> function, it is  possible in XSLT 1.0 to process multiple input documents as part of a transformation. However, frequently it is also convenient for a transformation to produce multiple <i>output</i> documents as well. As a simple example, consider the process of transforming the XML source of a technical manual. It may be desirable to produce the transformed output which separates each chapter into its own HTML document. XSLT 1.0 provides an <code>&lt;xsl:output&gt;</code> element that allows a stylesheet developer to control various aspects of how the result tree will be serialized, however it only supports the result tree being serialized to a single document.</p>
<p>XSLT 1.1 will support producing multiple output documents with the following requirements:</p>
<ul>
<li>It MUST be possible to specify the destination URI (e.g. file name) of each output document</li>
<li>It MUST be possible to assign the name of the destination URI  dynamically</li>
<li>It MUST be possible to control serialization of each output document using the same facilities as <code>&lt;xsl:output&gt;</code>
</li>
</ul>
<h2><a name="section-Requirements-for-Result-Tree-Fragment-to-Node-set-Conversion"></a>5 Requirements for Result Tree Fragment to Node-set Conversion</h2>
<p>The XSLT 1.0 specification distinguishes between the XPath node-set data type and the XSLT data type called a "<a href="http://www.w3.org/TR/xslt#section-Result-Tree-Fragments">result tree fragment</a>". A result tree fragment is treated equivalently to a node-set that contains just a single root node. However, the operations permitted on a result tree fragment are a subset of those permitted on a node-set. In XSLT 1.0, an operation is permitted on a result tree fragment only if that operation would be permitted on a string. In particular, it is not permitted to use the <code>/</code>, <code>//</code>, and <code>[]</code> operators on result tree fragments.</p>
<p>Many XSLT processors have introduced built-in extension functions to convert result tree fragments to node-sets so that they can be further processed, effectively eliminating the restrictions described above for the result tree fragments. The restrictions on the operations permitted on result tree fragments were designed in a forward-thinking way to allow relaxation of the restrictions in a future release, allowing the distinction between node-sets and result tree fragments to disappear without breaking upward compatbility. By eliminating this distinction in XSLT 1.1, the need for a result tree fragment to node-set conversion function is eliminated and cross-processor portability is improved.</p>
<h2><a name="section-Requirements-for-XML-Base-Support"></a>6 Requirements for XML Base Support</h2>
<p>Section 3.2 of the XSLT 1.0 specification,<a href="http://www.w3.org/TR/xslt#base-uri">Base URI</a>,  describes how the base URI is derived for every node in the data model. The specification must be updated to reflect how the base URI is derived in the presence of an <a href="http://www.w3.org/TR/xmlbase#IDw1Aq1">xml:base</a> attribute in scope.</p>
<h2><a name="section-References"></a>7 References</h2>

<h3><a name="section-Normative-References"></a>7.1 Normative References</h3>

<dl>

<dt>
<a name="XSLT">XSLT</a>
</dt>
<dd>World Wide Web Consortium. <i>XSL Transformations (XSLT) 1.0</i>
W3C Recommendation. See
 <a href="http://www.w3.org/TR/1999/REC-xslt-19991116">http://www.w3.org/TR/1999/REC-xslt-19991116</a>

 </dd>
<dt>
<a name="XMLBase">XMLBase</a>
</dt>
<dd>World Wide Web Consortium. <i>XML Base</i>
W3C Working Draft. See
 <a href="http://www.w3.org/TR/xmlbase">http://www.w3.org/TR/xmlbase</a>

 </dd>
</dl>


</body>
</html>