This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
XSLT and XPath development are no longer synchronized and it is quite possible that an XPath 3.1 specification will be published during the lifetime of XSLT 3.0. We should therefore consider whether XSLT should adopt the same policy as for other dependencies such as Unicode, XML, and XSD, namely to allow use of XSLT 3.0 with XPath 3.0 or any later version. This would have to take into account the possibility of data model changes. My proposal would be that an XSLT 3.0 processor * may allow use of versions of XPath, F+O, and Serialization later than 3.0 * must reject any XPath expression with a static or dynamic error as appropriate if it returns a value that is outside the value space of XDM 3.0. (For example, an array). (But note, we currently allow extension functions to return values that are outside the value space of XDM 3.0. So perhaps in the second rule, "must reject" should be "may reject") If future versions of XPath extend the static or dynamic context, then such extended parts of the context should take an implementation-defined value.
The WG considered this on 2014-03-21 and there was some sympathy for the idea. The editor was asked to propose detailed wording. Here is the proposal: The following paragraph appears in 26.1 Basic XSLT processor: The mandatory requirements of this specification are taken to include the mandatory requirements of XPath 3.0, as described in [XPath 3.0]. A requirement is mandatory unless the specification includes wording (such as the use of the words should or may) that clearly indicates that it is optional. Move this provision out of 26.1 into 26, because it applies to all XSLT processors not only to Basic processors; and expand it as follows: The mandatory requirements of this specification are taken to include the mandatory requirements of [XPath 3.0], [Data Model], and [Functions and Operators]. An XSLT 3.0 processor MUST provide a mode of operation which conforms to the 3.0 versions of those specifications as extended by [21 XPath Extensions]. It MAY also provide a mode of operation which conforms to later versions of those specifications; in such cases the detail of how XSLT 3.0 interacts with new features introduced by such later versions (for example, extensions to the data model) is *implementation-defined*. In 26.3 Serialization Feature add a paragraph: A processor that claims conformance with the Serialization Feature must satisfy the mandatory requirements of [Serialization]. It MUST provide a mode of operation which conforms to the 3.0 version of that specification. It MAY also provide a mode of operation which conforms to a later version of that specification; in such cases the detail of how XSLT 3.0 interacts with new features introduced by such a version (for example, support for new serialization properties) is *implementation-defined*.
The WG today agreed this change.
The change has been applied.