Bug #3450
Updated by Michael Kay over 6 years ago
The stylesheet used in issue #3443 is only working because of a bug in Saxon. At line 69 of sharedFunctions.xsl, it does int:max(($pValidFromDate, @validFromDate)) where $pValidFromDate is of type xs:date, while @validFromDate is an untyped attribute, and therefore has type xs:untypedAtomic when atomized. The function int:max() invokes xsl:sort to sort the supplied sequence. The spec says (in both XSLT 2.0 and 3.0) [ERR XTDE1030] It is a dynamic error if, for any sort key component, the set of sort key values evaluated for all the items in the initial sequence, after any type conversion requested, contains a pair of ordinary values for which the result of the XPath lt operator is an error. If the processor is able to detect the error statically, it may optionally signal it as a static error. So, for example, sorting Comparing an xs:date and an xs:untypedAtomic using the lt operator is an error, so this should fail. Saxon is actually converting the untypedAtomic value to an xs:date. Saxon is not detecting the error. I will log a bug on this. I hate fixing bugs where the fix will cause working code to break, but I think the case is clear-cut. I think the approach Saxon is taking will actually give a well-defined result if the sequence that only contains a mix of xs:untypedAtomic and xs:date values one other type (or multiple types if they are mutually comparable, like xs:double and xs:decimal). The rule is protecting against non-transitive comparisons for a case like ("3", untypedAtomic("10"), 4) - but that would fail anyway. I have created W3C test case sort-080. The test case should be throw XTDE1030; it is currently producing a type error. success result. This should also be an error under the rules of XQuery "order by" (where it raises XPTY0004), and under the rules of the fn:sort() function. It seems that Saxon has never raised an error in this situation: instead the comparison it uses to compare items in the sequence uses the rules of the "general comparison" operators, by converting xs:untypedAtomic to the type of the other value. Fixing this problem may cause existing applications to fail. I have therefore decided not to fix it until the next major release after 9.8. function
.