6871 2009-05-08 12:28:00 +0000 [FO] Erronneous value comparison operator mapping for xs:time? 2012-03-29 08:02:11 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Functions and Operators 1.0 Working drafts PC Linux CLOSED FIXED P2 minor --- 1 bogdanb+w3c+bugzilla mike public-qt-comments oldest_to_newest 25025 0 bogdanb+w3c+bugzilla 2009-05-08 12:28:00 +0000 Hello, Currently the spec at http://www.w3.org/TR/2007/REC-xpath-functions-20070123/ contains the following notes: *** quote *** 10.4.12 op:time-equal [...] This function backs up the "eq", "ne", "le" and "ge" operators on xs:time values. 10.4.13 op:time-less-than [...] This function backs up the "lt" and "le" operators on xs:time values. 10.4.14 op:time-greater-than [...] This function backs up the "gt" and "ge" operators on xs:time values. *** end quote *** However, according to http://www.w3.org/TR/2007/REC-xquery-20070123/#mapping the operators are mapped thus: A eq B -> op:time-equal(A, B) A ne B -> fn:not(op:time-equal(A, B)) A gt B -> op:time-greater-than(A, B) A lt B -> op:time-less-than(A, B) A ge B -> fn:not(op:time-less-than(A, B)) A le B -> fn:not(op:time-greater-than(A, B)) The mapping would suggest that op:time-equal backs up "eq" and "ne"; op:time-greater-than backs up "gt" and "le"; and op:time-less-than backs up "lt" and "ge". However I'm not sure the mapping in the XQuery spec is what is intended: Using that mapping, two xs:time values that should be incomparable because of time-zone differences would return false from the "eq", "gt" and "lt" operators, but true for "ne" (correct), "ge" and "le"—the latter two would seem wrong. To reflect incomparable values, the "le" and "ge" operators should map to “op:time-less-than(A, B) or op:time-equal(A, B)” and “op:time-greater-than(A, B) or op:time-equal(A, B)”, respectively, similar to how numeric values are compared. I think something similar should apply to xs:dateTime, but I haven't checked thoroughly that case yet. 25134 1 mike 2009-05-13 12:00:19 +0000 >The mapping would suggest that op:time-equal backs up "eq" and "ne"; op:time-greater-than backs up "gt" and "le"; and op:time-less-than backs up "lt" and "ge". Yes, I think that's correct, and the "backs up" statements should be corrected. >However I'm not sure the mapping in the XQuery spec is what is intended: Using that mapping, two xs:time values that should be incomparable All xs:time values are comparable using these operators. Timezone differences are handled by applying the implicit timezone. I'm not absolutely sure whether the two possible definitions of the operators are equivalent, for example whether not($s lt $t) is always equivalent to ($s eq $t or $s gt $t), but to avoid depending on this we should be consistent in how it's defined. 25179 2 bogdanb+w3c+bugzilla 2009-05-16 09:15:15 +0000 (In reply to comment #1) > >However I'm not sure the mapping in the XQuery spec is what is intended: Using > that mapping, two xs:time values that should be incomparable > > All xs:time values are comparable using these operators. Timezone differences > are handled by applying the implicit timezone. You're right, I'm sorry. This part of my report should be disregarded. I think I had mixed up the XQuery and XML Schema specs. > I'm not absolutely sure whether the two possible definitions of the operators > are equivalent, for example whether not($s lt $t) is always equivalent to ($s > eq $t or $s gt $t), but to avoid depending on this we should be consistent in > how it's defined. They are equivalent whenever the operators create a total order. IIRC, xs:times with and without timezones are not totally ordered in the sense of XML Schema, but they are totally ordered with respect to the XQuery gt/lt/eq operators. The implicit timezone bridges the two “ordering domains”. That's what confused my original report. Should the original description be edited, or are these comments enough? 25890 3 mike 2009-07-07 15:32:52 +0000 Agreed that we will change the "backs up" sentences to match what's in the table. This is editorial so we are marking it FIXED. 66219 4 mike 2012-03-29 08:02:11 +0000 I discovered that this change had not been applied in the 3.0 specifications, and I have now applied it (affects the less-than and greater-than functions for date, time, and dateTime). I have also added this to the list of candidate errata for the 1.0/2.0 specification. I am now taking the opportunity to mark the bug closed, so it no longer comes up as needing attention.