[Bug 29830] New: [FO31] Unclear what happens w.r.t. backwards / forwards compatibility in fn:transform

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29830

            Bug ID: 29830
           Summary: [FO31] Unclear what happens w.r.t. backwards /
                    forwards compatibility in fn:transform
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Functions and Operators 3.1
          Assignee: mike@saxonica.com
          Reporter: abel.braaksma@xs4all.nl
        QA Contact: public-qt-comments@w3.org
  Target Milestone: ---

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".

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 20 September 2016 12:49:29 UTC