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 26648 - [XSLT30] edge cases for numeric package version components comparisons
Summary: [XSLT30] edge cases for numeric package version components comparisons
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Last Call drafts
Hardware: PC Windows NT
: 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: 2014-08-24 13:51 UTC by Abel Braaksma
Modified: 2014-09-04 19:42 UTC (History)
0 users

See Also:


Attachments

Description Abel Braaksma 2014-08-24 13:51:11 UTC
This was first covered in an email discussion, see https://lists.w3.org/Archives/Member/w3c-xsl-wg/2014Aug/0014.html and https://lists.w3.org/Archives/Member/w3c-xsl-wg/2014Aug/0015.html (member only).

Summary: numeric version components are compared numerically according to the new 3.6.1 section. Numeric overflow might happen when doing such comparisons. The proposal in 0015.html is to describe the behavior in terms of the XPath gt, lt and eq operators.

Maybe we can do the same for the string comparisons?

As mentioned in 0023.html, I think there is no need to re-cast XPath errors to be XSLT errors for such (very rare) edge cases.
Comment 1 Michael Kay 2014-09-04 19:41:59 UTC
The WG accepted a suggestion that we can handle this by ensuring that the rules for comparing integers in version numbers are defined by reference to the XPath operator rules, which include rules for limits, overflow, and similar edge cases.

To apply this, I have:

(a) specified that the integers follow the rules for XPath IntegerLiterals (with mention that this includes the rules on limits)

(b) specified that comparison of integers or of NCNames follows the rules for XPath value comparisons.