This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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".
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)
The WG agrees. Marking at editorial.
The spec has been clarified as suggested.