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 29880 - package-version - limits
Summary: package-version - limits
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Candidate Recommendation
Hardware: PC All
: 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: 2016-09-29 09:59 UTC by Michael Kay
Modified: 2016-10-26 11:44 UTC (History)
1 user (show)

See Also:


Attachments

Description Michael Kay 2016-09-29 09:59:51 UTC
Test package-version-903 uses the ridiculous

package-version= "123456789123456789123456789123456789123456789123456789123456789123456789.1234....

An implementation can actually throw this one out under the current rules (more than 16 digits), but I don't think we should require implementations to support version number portions as high as 16 digits. 

Note: on .NET the components of a version number are limited to the range 1..65534. There is also a maximum of four components.

SEMVER, which we reference non-normatively, has a maximum of three components. It doesn't limit the range of each component but tells you to use common sense.

I propose we say that an implementation is required to accept a version number with up to three numeric components each in the range 0..9999, and is allowed to reject anything outside these ranges.
Comment 1 Abel Braaksma 2016-09-29 13:44:19 UTC
Yes, it's definitely a ridiculous version number, I believe I added it to test our version parser, which parses it fine, but cannot use it in version comparison as that uses native 64 bit integers.

I wasn't aware of the 16 digit limitation, I don't see that in the spec.

I don't think we should limit it to arbitrary ranges, though. It is not inconceivable that versions will match build versions of a containing product, and there are several out there (at least in the .NET world) with four segments and at least one segment (usually the build no) that have five digits.

However, I think it makes sense to limit it to, say, the range xs:unsignedInt. 

Also, I don't think a processor should reject anything if the version appears on the principal package. Instead, I propose that it may fail to find a matching package if such outerworldly package numbers are used in version ranges on xsl:use-package.

Same is true for the number of version components. I don't think we ought to limit that. We made a conscious decision at the time to make the version number as unrestrictive as possible. Though if we do decide in favor of limitation, I think four is a better number of components (because a large body of existing software, namely everything on Windows, uses four-component version numbers).
Comment 2 Michael Kay 2016-10-13 15:32:26 UTC
I propose:

A processor may impose limits on these values but must allow:

* any IntegerLiteral value in the range 1 to 65535

* up to four IntegerLiteral values

* an NCName of up to 128 characters
Comment 3 Michael Kay 2016-10-26 11:12:41 UTC
The minutes for 20 Oct 2016 record:

RESOLVED: to close bug 19880 by allowing processors to impose limits
on package version identifiers. Processors MUST accept identifiers up
to [specified limits] and MAY accept longer identifiers. We agreed on
4 segments, 999999, and 100 characters in the NCName as the limits.
Comment 4 Michael Kay 2016-10-26 11:44:49 UTC
The spec has been updated.

The problem test actually appears to be package-version-012. This has been updated to allow an error result. Ditto package-version-013.

A new test that tests the limits is added (package-version-019).