Copyright ©2000 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document describes the requirements for the XSLT 1.1 specification.
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.
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 W3C membership.
This document has been produced as part of the W3C Style activity, following the procedures set out for the W3C Process. The document has been written by the XSL Working Group ( W3C members only). The goals of the XSL Working Group are discussed in the XSL Working Group charter. The XSL Working Group feels that the contents of this Working Draft are relatively stable, and therefore encourages feedback on this version.
Comments on this document should be sent to the W3C mailing list xsl-editors@w3.org (archived at http://lists.w3.org/Archives/Public/xsl-editors/). A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/.
In addition to supporting user-defined extensions, numerous XSLT 1.0-compliant processors have exploited the XSLT 1.0 extension mechanism to provide additional built-in 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 [XSLT]) provides no details or guidance on the implementation 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.
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:
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.
A secondary goal of the XSLT 1.1 specification is to support the new XML Base (See [XMLBase]) specification.
This document provides the requirements that will achieve these goals.
NOTE: 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 functions. Standardization of extension elements and support for new XML Schema data type aware facilities are planned for XSLT 2.0
Upward compatibility of XSLT stylesheets is an important criteria for existing users. To this end, we have the following requirements:
version number to a number greater than 1.0, it MUST clearly explain the rules for forward compatibility of version="1.0" stylesheets and the restrictions, if any, on the use of new features in stylesheets with version="1.0".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. myprefix:myfunction(). It provides the function-available() 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:
Using the document() 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 output 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 <xsl:output> 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.
XSLT 1.1 will support producing multiple output documents with the following requirements:
<xsl:output>
The XSLT 1.0 specification distinguishes between the XPath node-set data type and the XSLT data type called a "result tree fragment". 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 /, //, and [] operators on result tree fragments.
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.
Section 3.2 of the XSLT 1.0 specification,Base URI, 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 xml:base attribute in scope.