[Bug 26443] New: [XSLT30] xsl:use-package/@package-version is defined as a token, but can take any string, and appears to act as regex (?)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug 26443] New: [XSLT30] xsl:use-package/@package-version is defined as a token, but can take any string, and appears to act as regex (?)

Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26443

            Bug ID: 26443
           Summary: [XSLT30] xsl:use-package/@package-version is defined
                    as a token, but can take any string, and appears to
                    act as regex (?)
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: minor
          Priority: P2
         Component: XSLT 3.0
          Assignee: [hidden email]
          Reporter: [hidden email]
        QA Contact: [hidden email]

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.

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

Reply | Threaded
Open this post in threaded view
|

[Bug 26443] [XSLT30] xsl:use-package/@package-version is defined as a token, but can take any string, and appears to act as regex (?)

Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26443

--- Comment #1 from Abel Braaksma <[hidden email]> ---
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.

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

Reply | Threaded
Open this post in threaded view
|

[Bug 26443] [XSLT30] xsl:use-package/@package-version is defined as a token, but can take any string, and appears to act as regex (?)

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26443

--- Comment #2 from Michael Kay <[hidden email]> ---
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)

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

Reply | Threaded
Open this post in threaded view
|

[Bug 26443] [XSLT30] xsl:use-package/@package-version is defined as a token, but can take any string, and appears to act as regex (?)

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26443

Michael Kay <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #3 from Michael Kay <[hidden email]> ---
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.

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

Reply | Threaded
Open this post in threaded view
|

[Bug 26443] [XSLT30] xsl:use-package/@package-version is defined as a token, but can take any string, and appears to act as regex (?)

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26443

Michael Kay <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #4 from Michael Kay <[hidden email]> ---
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.*)

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

Reply | Threaded
Open this post in threaded view
|

[Bug 26443] [XSLT30] xsl:use-package/@package-version is defined as a token, but can take any string, and appears to act as regex (?)

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26443

Michael Kay <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #5 from Michael Kay <[hidden email]> ---
The changes have been applied to the spec.

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