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 26443 - [XSLT30] xsl:use-package/@package-version is defined as a token, but can take any string, and appears to act as regex (?)
Summary: [XSLT30] xsl:use-package/@package-version is defined as a token, but can take...
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-07-28 16:32 UTC by Abel Braaksma
Modified: 2014-08-01 19:07 UTC (History)
0 users

See Also:

Attachments

Description Abel Braaksma 2014-07-28 16:32:06 UTC 
We are trying to understand the text under section 3.6.1 Dependencies between Packages. The current relevant text is as follows:

> The value of the package-version attribute consists of a prefix 
> and a suffix separated by a hash sign (#); if there is no hash 
> sign, the entire string is used as the prefix, and the suffix is 
> empty; if there is more than one hash sign, the first one is taken 
> as the separator and others as part of the suffix; if the hash sign 
> is the last character in the string then a suffix of ".*" is 
> assumed. The pattern matches a package version if the package 
> version can be divided into two substrings such that the first 
> substring matches the prefix literally (using codepoint comparison), 
> and the second substring matches the suffix considered as a regular 
> expression (matched according to the rules of the matchesFO30 function 
> with the $flags argument set to a zero length string). Thus the
> version pattern 3.1 matches version 3.1 only; the pattern 3.1# 
> matches 3.1, 3.1.2, and 3.17; the pattern 3.1#(\.\d+)? matches 3.1 and
> 3.1.5; and the pattern 3.1#(\.\d+)* matches 3.1, 3.1.5, and 3.1.5.2.

Issues:
- @package-version is defined as type token, but not so on xsl:package and not so in the XSL XSD Schema (in both cases it is xs:string)
- the text above uses example values like "3.1#(\.\d+)*", but the text does not explicitly say that the value is regular expression
- all examples talk of digits and dots. However, I think/assume that letters are allowed, such as package-version="1.4.3b" or "1.4.3-beta".
- should the value indeed be interpreted as a regex, i.e. that package-version="[a-z]+" is allowed and matches "alfa" and "gamma"?
- Or perhaps the intend of the text is to show how "#" can be expanded as a regular expression, and that, apart from the "#"-sign, no other metacharacters are interpreted as metacharacters, they are just literals. In which case some examples in the text should be fixed.

On a second and third read, it looks like it is meant as a production of something like:

PackageVersion ::= Prefix ("#" Suffix)?
Prefix ::= [^#x23]*
Suffix ::= regExp

Where Prefix is any valid Char, except the hash-sign and regExp matches the production of regular expressions in XPath/XSD.
Comment 1 Abel Braaksma 2014-07-30 15:19:43 UTC 
We discussed this at the F2F Hursley 30 July 2014.

Instead of the current complex syntax with (in part) regular expressions, the WG decided to simplify the schema for package versions:

1) The package version must consist of digits separated by dots, which implies an ordering
2) The xsl:use-package should specify a single range of acceptable versions, for which the following possibilities are created:
  a) range can be open-ended on either end
  b) range can be close-ended on either end
  c) close-ended ranges can be either inclusive or exclusive
  d) we prefer to avoid the geeky syntax used by Maven, like "[1.0,2.4)".

Abel will come up with a proposal for this.
Comment 2 Michael Kay 2014-07-31 15:50:18 UTC 
Florent pointed us to SemVer

http://semver.org

which seems to provide some kind of standard in this area for identifying versions of components (but not a syntax for defining a range of versions)
Comment 3 Michael Kay 2014-07-31 16:15:20 UTC 
Proposal:

(a) The syntax of version id's is as defined in SemVer. 

(b) We express the required version using an attribute with the syntax

"#any" | (version)? ("or higher" | ("to" (version ("inclusive"|"exclusive")?)?))?

where "version" is as defined in SemVer (allowing omission of least significant components), and ordering of versions is as defined in SemVer.

We are uncomfortable that SemVer requires exactly three numeric components in the version number (major.minor.patch). Could/Should we generalize it to a variable number of numeric components?

Action is on Abel to produce a detailed proposal along these lines.
Comment 4 Michael Kay 2014-08-01 09:26:34 UTC 
We resolved to go with the following, subject to bug-checking and turning into spec prose:

A version is a dot-separated sequence of integers followed optionally by a (hyphen followed by a name).

version ::= integer ("." integer)* ("-" NCName)?

Refer to the integers and NCName as "components".

Versions are ordered. To compare two versions, 

(a) trailing zero components (before the hyphen) are discarded (so 1.2 = 1.2.0)

(b) comparison is then component-by-component, compared pairwise. If one version is a prefix of the other, then it comes first if the remainder is numeric (e.g. 2 < 2.3) but last if the remainder is an NCName (e.g. 2.3-alpha < 2.3). If all components are pairwise equal, the versions are equal. Otherwise, the ordering depends on the first component that differs.

Components are compared as follows: if both are integers, they are compared numerically; if both are NCNames, they are compared by codepoint collation; if one is an NCName and one is an integer, the NCName comes first.

Thus 0-rc1 < 0-rc2 < 0 < 1 = 1.0 < 1.0.2 < 1.0.3-rc1 < 1.0.3 < 1.0.10

use-package defines a version range. A version range is one of:

"*" (any version)

version (exact match)

version "+" (greater than or equal)

version ".*" (must match a prefix - matches v-n as well as v.N)

range ("," range)+ (a union of ranges)

"to" version (less than or equal)

"to" version ".*" (less than or equal to the highest version that matches v.*)

version "to" version (inclusive range)

version "to" version ".*" (exclusive range, e.g. 1 to 3.*)
Comment 5 Michael Kay 2014-08-01 19:07:44 UTC 
The changes have been applied to the spec.