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 26780 - [XSLT30] Editorial: forwards compatibility mode and packages
Summary: [XSLT30] Editorial: forwards compatibility mode and packages
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Last Call drafts
Hardware: PC Windows NT
: P2 minor
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-11 00:03 UTC by Abel Braaksma
Modified: 2015-10-29 09:50 UTC (History)
0 users

See Also:


Attachments

Description Abel Braaksma 2014-09-11 00:03:25 UTC
We say, under 3.6 Packages:
"The version attribute indicates the version of the XSLT language specification to which the package manifest conforms. The value SHOULD be 3.0."

Before we merged xsl:stylesheet into xsl:package, this made sense, because on the child xsl:stylesheet one could still specify another version. Except that as written it limited the way you could use forwards or backwards compatibility mode on children of xsl:package.

Now that all declarations are allowed as children of xsl:package, it has become more synonymous with xsl:stylesheet. I think we should bring the description of the allowed values for the version attribute in line to allow the same kinds of forwards compatibility processing (and perhaps even backwards compatibility processing, though I think a version lower than 3.0 would yield an error either way) as xsl:stylesheet had.
Comment 1 Abel Braaksma 2014-09-13 13:39:59 UTC
As discussed by mail (see https://lists.w3.org/Archives/Member/w3c-xsl-wg/2014Sep/0030.html and previous, member only), the conclusion was:

- I misinterpreted the spec, the "SHOULD" does not preclude forwards/backwards
  compatibility mode on package manifests

- The suggestion in the mail by MKay was to change the sentence as follows, 
  which prompted me to mark this bug as Editorial.

Textual proposal from MKay:

> "For this version of XSLT, the value SHOULD normally be 3.0. Specifying a
> different value invokes backwards-compatible processing (see 3.10), or 
> forwards-compatible processing (see 3.11)."

Marked EDITORIAL.
Comment 2 Michael Kay 2014-10-08 15:54:36 UTC
This was resolved editorially prior to publishing the LCWD on 2 October 2014.