This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 29830 - [FO31] Unclear what happens w.r.t. backwards / forwards compatibility in fn:transform
Summary: [FO31] Unclear what happens w.r.t. backwards / forwards compatibility in fn:t...
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.1 (show other bugs)
Version: Candidate Recommendation
Hardware: PC Windows NT
: P2 editorial
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2016-09-20 12:49 UTC by Abel Braaksma
Modified: 2016-12-16 19:55 UTC (History)
1 user (show)

See Also:


Description Abel Braaksma 2016-09-20 12:49:04 UTC
At one point, the text explains that you can either do a 1.0, 2.0 or 3.0 transform with a 1.0, 2.0 or 3.0 processor. We use phrases like:

"For invocation of an XSLT 1.0 processor (see [XSL Transformations (XSLT) Version 1.0]), the supplied options MUST include all of the following and nothing else:" 

Later on we say (bottom of table):

"The minimum level of the XSLT language that the processor must support. Defaults to the [xsl:]version attribute at the outermost level of the stylesheet."

These two statements are in conflict with each other.

- Do we want to limit the abilities by having either of a 1.0, 2.0 or 3.0 *processor*
- Or do we want to set the option of any available processor to 1.0, 2.0, 3.0, if such option exists, possibly processing in forwards or backwards compatibility mode
- Or do we want both?

I would prefer to allow users freedom of choice. That is:
- a 3.0 stylesheet can be processed with a 2.0 or 3.0 processor
- a 1.0 stylesheet can be processed with a 2.0 or 3.0 processor, and if backwards-compatibility mode is supported it is used
- etc

To allow this freedom, I suggest we either change the wording or add an extra map item, say "supported-xslt-version".
Comment 1 Michael Kay 2016-09-20 18:42:44 UTC
I think the intended behaviour is:

* you request a processor that is an implementation of a specific version of XSLT using the xslt-version option, which defaults to the version attribute of the top-level stylesheet module/package. Let's say the version you request is V.

* the system gives you a processor that supports that version or a higher version, say W.

* the processor then goes into forwards or backwards compatibility mode based on the rules of XSLT version W, for example if W = 3.0 and the stylesheet specifies version = 1.0 then it goes into backwards compatibility mode; if W = 2.0 and the stylesheet specifies version 3.0 then it goes into forwards compatibility mode.

I agree that this could usefully be clarified in the spec. (I think that this is essentially editorial)
Comment 2 Andrew Coleman 2016-09-27 15:22:04 UTC
The WG agrees.  Marking at editorial.
Comment 3 Michael Kay 2016-09-27 19:50:08 UTC
The spec has been clarified as suggested.