This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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).
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
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.
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).