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 28215 - [XSLT30] Errors in EBNF for VersionTo and VersionRange and some ambiguities in the accompanying text
Summary: [XSLT30] Errors in EBNF for VersionTo and VersionRange and some ambiguities i...
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 normal
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: 2015-03-14 17:01 UTC by Abel Braaksma
Modified: 2015-10-29 09:50 UTC (History)
0 users

See Also:

Attachments

Description Abel Braaksma 2015-03-14 17:01:01 UTC 
For reference, the current productions for PackageVersion and PackageRanges are:

PackageVersion   ::= NumericPart ( "-" NamePart )?
NumericPart      ::= IntegerLiteral ( "." IntegerLiteral )*
NamePart         ::= NCName

PackageVersionRange ::=  AnyVersion | VersionRanges
AnyVersion          ::=  "*"
VersionRanges       ::=  VersionRange (S? "," S? VersionRange)*
VersionRange        ::=  VersionPrefix | VersionFrom | VersionTo | VersionFromTo
VersionPrefix       ::=  PackageVersion ".*"
VersionFrom         ::=  PackageVersion "+"
VersionTo           ::=  "to" S VersionPrefix
VersionFromTo       ::=  PackageVersion S "to" S (PackageVersion | VersionPrefix)

The first two items below are the bug, the last three are editorial suggestions.

** ITEM 1 **
Bug 26997 fixed VersionFromTo, but the same fix (the part after the "to" keyword) should also be applied on VersionTo, otherwise the examples, the intended meaning and the explanation in the text do not match, as "to 2.1" would be invalid):

VersionTo  ::= "to" S (PackageVersion | VersionPrefix)

** ITEM 2 **
The text on VersionPrefix says that all components must match. It is unclear what "1.2-alpha.*" would match. The intention of a user might be to match "1.2-alphaBuild1" and "1.2-alphaBuild7", but not "1.2-prod". But the NCName is a component as mentioned in the text, so it seems to be that "1.2-alpha.*" only ever matches a version that is exactly "1.2-alpha".

I think that mentioning this in the bulletpoint on VersionPrefix proves beneficial.

** ITEM 3 **
(editorial)
The term "component" is rather unclear and generic. My (editorial) suggestion is to change it to "version component" or even "package version component" and to interlink and define it as a real definition. Now the rest of the text and the explanation of the term "component" are not clearly linked and/or understood as such, leading to (in our case) a very confusing discussion between the programmers.

In addition, I think we should make it very clear that there is at most one non-numeric component (even though the production already shows this) and that even "1.0-alpha.b.2a-5b" is legal and has one NamePart, namely "alpha.b.2a-5b".

** ITEM 4 **
(editorial)
"The integers and optional NCName within the version number are referred to as the components of the version number."

This should probably be s/NCName/NamePart/:
"The integers and optional NamePart within the version number are referred to as the components of the version number."

And maybe even: s/integers/IntegerLiteral/, as "integers" is not mentioned in the production.

** ITEM 5 **
(editorial)
Layout: the second production, on PackageVersionRange, is indented eight spaces in the spec, the first part, on PackageVersion, is not.
Comment 1 Abel Braaksma 2015-03-14 17:55:59 UTC 
(Editorial)
In addition, I think it would help if we add some more examples, esp. where it concerns NamePart, as that may cause confusion (as we found while discussing it). Here are some suggestions we thought of (the bullet points as they are now are quoted):

<quote>
The range VersionRanges matches a version if any constituent VersionRange matches that version.
<quote>

<suggestion>
[...]. For example: "2.3" matches only 2.3, "2.3, 2.4 to 3.3.*" matches 2.3, 2.4.5, 3.2, 3.3.4 but not 3.4, "1.2, 1.4, 1.6" only matches those specific versions, "1.1-alpha, 1.2.*" matches 1.1-alpha exactly, 1.2, 1.2.5, 1.2-beta but not 1.1 or 1.3.
</suggestion>

<quote>
The range VersionPrefix matches any version whose leading components are the same as the components listed. For example, 1.3.* matches 1.3,  1.3.5,  1.3.10.2,  and 1.3-beta.
</quote>

<suggestion>
[...] but not 1 or 1.4. And 3.5-beta.* matches only the exact version 3.5-beta, not 3.5-beta.1 or 3.5-beta-build3.
</suggestion>

<quote>
The range VersionFrom matches any version that is greater than or equal to the version supplied. For example 1.3+ matches 1.3,  1.3.2,  1.4,  or 2.1.
</quote>

<suggestion>
[...] but not 1.3-alpha or 1.2. And 1.3-alpha+ matches 1.3.beta, 1.3.0, 1.4, 5.2, but not 1.3-alph or 1.3-a2.
</suggestion>

<quote>
The range VersionTo matches any version that is less than or equal to some version that matches the VersionPrefix. For example, to 4.0 matches 1.5,  2.3,  3.8,  4.0,  and 4.0-beta (but not 4.0.1), while to 3.3.* matches 1.5 or 2.0.6 or 3.3.4621, but not 3.4.0 or 3.4.0-beta.
</quote>

Nothing to add, I don't see ambiguities.

<quote>
The range VersionFromTo matches any version that is greater than or equal to the starting PackageVersion, and less than or equal to some version that matches the VersionPrefix. For example, 1 to 5 matches 1.1,  2.1,  3.1,  or 5.0 (but not 5.1), while 1 to 5.* matches all of these, plus versions such as 5.7.2 (but not 6.0 or 6.0-beta).
</quote>

<suggestion>
[...] And 1.0-beta to 1.0 matches 1.0-beta, 1.0-beta.build1, 1.0, 1.0-gamma but not 1.0.1, 1.0-alpha or 1.0-b.
</suggestion>

(I hope I understood the rules correctly when writing these examples. If they don't end up in the spec, they can perhaps be used in test cases)
Comment 2 Abel Braaksma 2015-03-17 13:11:40 UTC 
There's another important bug with versions, it seems not possible to use single versions in a version range, as in package-version="1.0", or a range, as in package-version="1.2, 1.4, 1.6".

One way to fix this is to allow PackageVersion in the VersionRange production:

VersionRange  ::=  PackageVersion | VersionPrefix | VersionFrom | VersionTo | VersionFromTo


Also, it appears slightly ambiguous whether a version range follows the production rules of PackageVersion *or* PackageVersionRange, or whether it follows the production of only PackageVersionRange. I think the latter is meant. The relevant text is in 3.6.2. Dependencies between Packages, 6th para:

<quote>
The value of the package-version attribute, if present, must conform to the rules for a version range given in 3.6.1 Versions of a Package;
</quote>

A fix could be to write instead:

<proposal>
The value of the package-version attribute, if present, must conform to the production of PackageVersionRange and the rules for such version range given in 3.6.1 Versions of a Package;
</proposal>
Comment 3 Michael Kay 2015-04-17 11:57:07 UTC 
The WG accepted this, subject to detailed review by the editor.

I have implemented changes as follows:

COMMENT 0

ITEM 1: fixed this bug

ITEM 2: I have clarified that the ".* matches additional components, it does not cause a substring match on the final component, and I have given examples to illustrate this. I've also pointed out that the final NCName can include "." and "-" as ordinary characters and these do not act as component separators.

ITEM 3: I replaced "component" by "portion", as a defined term.

ITEM 4 and 5: fixed as suggested.

COMMENT 1

I have incorporated most of the suggested examples into the spec.

COMMENT 2

Fixed as suggested.