Bug #3450: Sorting a heterogeneous sequence - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #3450

closed

Sorting a heterogeneous sequence

Added by Michael Kay over 6 years ago. Updated over 6 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Michael Kay

Category:

XSLT conformance

Sprint/Milestone:

Start date:

2017-09-18

Due date:

% Done:

100%

Estimated time:

Legacy ID:

Applies to branch:

9.8

Fix Committed on Branch:

9.8

Fixed in Maintenance Release:

9.8.0.5

Platforms:

Description

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 a sequence that contains a mix of xs:untypedAtomic and xs:date values should be a type error.

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.

Actions

Copy link

Updated by Michael Kay over 6 years ago

I have also added test cases to QT3 test sets OrderByClause, fn-sort, and array-sort

Actions

Copy link

Updated by Michael Kay over 6 years ago

Description updated (diff)

Further information:

I found the problem while investigating the stylesheet used in issue #3443, which is only working because of this 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.

I think the approach Saxon is taking will actually give a well-defined result if the sequence only contains xs:untypedAtomic and 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 throw XTDE1030; it is currently producing a success result.

As a temporary measure I am committing a change to AtomicSortComparer on the 9.8 branch which (a) improves the diagnostics when non-comparable values appear in a sort sequence, and (b) contains a commented-out fix for this problem. Leaving the bug open until it is fixed on the trunk.

Actions

Copy link