30106 2017-05-04 10:18:53 +0000 [xslt30ts] Test case use-package-204 and matching multiple packages with a version range, which package is chosen? 2019-02-26 01:27:06 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Test Suite Proposed Recommendation PC All ASSIGNED P2 normal --- 1 mike abel.online abel.braaksma public-qt-comments oldest_to_newest 128564 0 mike 2017-05-04 10:18:53 +0000 The test case defines an environment containing 5 versions of package http://www.w3.org/xslt30tests/use-package-base-004, specifically 1.0.0, 2.0.0, 3.5.4, 2.0.0-alpha, and 2.0.0-beta. The xsl:use-package specifies package-version="1.5 to 2.5" The test results assume that 2.0.0 will be chosen. But the spec says(in §3.5.2) This specification does not define how the implementation locates a package given its name and version. If several matching versions of a package are available, it does not define which of them is chosen. 128586 1 abel.braaksma 2017-05-09 18:01:01 +0000 I follow your reasoning, but find it unfortunate. This means that the highest available version is *not* automatically chosen. Consider NuGet: it has the option to select "highest-major" or "highest-minor", or "exact-match". We have the machinery to do the same, but we don't use that machinery... I doubt we can change this (let alone at this stage). Though perhaps it is possible to add a recommended behavior, something like: "Implementers are encouraged to select the highest version available.". This would prevent too much implementation independence without changing the spec normatively. Anything else (not selecting the highest available version) seems rather odd to me. 128587 2 mike 2017-05-10 08:29:35 +0000 I suspect the reason we didn't mandate selection of the highest version was to allow implementations to factor in other criteria: for example a catalog might label a particular version as "preferred" or "stable", or it might have some kind of configuration parameter giving meaning to the NCName part of the version number e.g. 2.1-Saxon versus 2.1-Exselt. I agree that "highest version" is the most sensible thing to do in the absence of other information (and the test proved useful because it was failing because of a Saxon bug!) Perhaps we should just add a test dependency "highest_package_version". 128588 3 mike 2017-05-10 08:36:32 +0000 Another case where an implementation might reasonably choose not to use the highest version is if A requires B and C, B requires D version 2.3.1.4, and C requires D version * (any version). In that situation it makes sense for C to use the same version of D that B uses. 128914 4 abel.braaksma 2017-10-09 20:20:46 +0000 Yes, that makes sense (re: your last comment), although that may result in different behavior in different situations. I think predictability is a better thing to have. That said, since we won't be changing the spec in this regard, I do think it makes sense to add either an example or a Note in the spec that explains this particular situation. I've never considered this difference, and even though all examples in the package-version section say "x.y or z.w matches range so and so", i.e., they use "OR", it would be nice to have a specific example in XSLT that shows the use of the package-version attribute and the effect it has. Something like: Example: your package repository has version 1.2-alpha, 1.2, 1.2.1, 1.3 of package "urn:Foo" available and your processor can locate all of them, and you use the following declaration: <xsl:use-package name="urn:Foo" package-version="1.2+" /> Then it is processor-dependent whether your processor will load version 1.2, 1.2.1 or 1.3. However, it will never load 1.2-alpha. Conversely, if you have <xsl:use-package name="urn:Foo" package-version="1.2.1, 1.4.*" /> Then every processor will always load package version 1.2.1, assuming your package repository will not include 1.4.x at some point. 129571 5 abel.online 2019-02-26 01:23:50 +0000 (In reply to Abel Braaksma from comment #4) > it would be nice to have a specific example in XSLT that shows the > use of the package-version attribute and the effect it has. While this would be "nice", considering we are in REC status, I now think we shouldn't riddle the errata with (more) examples. Re-reading the comments below doesn't convince me something needs to be changed. (In reply to Michael Kay from comment #2) > I agree that "highest version" is the most sensible thing to do in the > absence of other information (and the test proved useful because it was > failing because of a Saxon bug!) Perhaps we should just add a test > dependency "highest_package_version". I have now changed the XSD as follows: - added "package_version_resolution" dependency - value can have: highest_version, lowest_version, unspecified - added documentation, though I think the intend is clear I have fixed the following tests with this dependency: - use-package-203 - use-package-204 - use-package-206 - use-package-210 Each is renamed to -203a etc, and a -203b/c (etc) have been added to allow for either outcome. Tests marked with "unspecified" behavior can be run by any processor. Processors that support choosing the highest version in a range, should update their drivers to select the "highest_version". If they support the lowest version in a range, then "lowest_version". Conversely, these dependencies could be used to switch the version-resolution algorithm, if a processor has such option. I'll leave this bug open for any comments.