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
OS: Windows NT
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 18.104.22.168.
- @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
--- 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
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.
What |Removed |Added
--- Comment #4 from Michael Kay <[hidden email]> ---
We resolved to go with the following, subject to bug-checking and turning into
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.