RE: XSLT 2.0: Sorting and indeterminate comparisons

Echoing Ashok's response, the current situation is that the "lt" operator,
if it is defined at all for a given data type, always returns a determinate
boolean answer. Defining sorting in terms of "lt" and "eq" therefore works.

I agree that if we allowed an indeterminate result of "lt" we could treat it
for sorting purposes as if the items were equal. Currently, the value of
P29D lt P1M is not indeterminate, it is an error. 

I expect that in a future draft we may list the data types that can be used
in xsl:sort. These are likely to include dayTimeDuration and
yearMonthDuration but not xsd:duration.

Michael Kay 

> -----Original Message-----
> From: Jeni Tennison [mailto:jeni@jenitennison.com]
> Sent: 09 May 2002 14:02
> To: public-qt-comments@w3.org
> Cc: xsl-editors
> Subject: XSLT 2.0: Sorting and indeterminate comparisons
> 
> 
> Hi,
> 
> [I didn't realise that the email address for XSLT 2.0 comments had
> changed as well...]
> 
> This is a follow-on from my last message about indeterminate
> comparisons between durations and date/times in the F&O WD and
> sorting. Currently the XSLT 2.0 WD says:
> 
>   The items in the initial sequence are ordered into a sorted sequence
>   by comparing their sort keys. The relative position of two items A
>   and B in the sorted sequence is determined as follows. The first
>   sort key of A is compared with the first sort key of B, according to
>   the rules of the first sort key definition. If, under these rules, A
>   is less than B, then A will precede B in the sorted sequence, unless
>   the order attribute of this sort key definition specifies
>   descending, in which case B will precede A in the sorted sequence.
>   If, however, the relevant sort keys compare equal, then the second
>   sort key of A is compared with the second sort key of B, according
>   to the rules of the second sort key definition. This continues until
>   two sort keys are found that compare unequal. If all the sort keys
>   compare equal, then A will precede B in the sorted sequence if A
>   preceded B in the initial sequence, and vice versa.
> 
>   In general, comparison of two values is performed according to the
>   rules of the XPath lt operator. However, special rules apply to
>   certain data types, as described below. [ERR069] It is a dynamic
>   error if, for any sort key definition, the set of sort keys
>   evaluated for all the items in the initial sequence, after any type
>   conversion requested, contains a pair of values for which the result
>   of the XPath lt operator is an error or an empty sequence. The
>   processor must either signal the error, or must recover by assigning
>   an arbitrary ordering to any such pair of values.
> 
> Given that indeterminate comparisons were allowed, I think that it
> would be much more helpful if the comparisons between pairs of values
> were described in terms of only lt rather than lt and eq. The second
> part of the first paragraph would be:
> 
>   If, however, B is not less than A, then the second sort key of A is
>   compared with the second sort key of B, according to the rules of
>   the second sort key definition. This continues until two sort keys
>   are found for which A is less than B or B is less than A. If all the
>   sort keys compare equal, then A will precede B in the sorted
>   sequence if A preceded B in the initial sequence, and vice versa.
> 
> For totally ordered data types, this makes no difference. For
> partially ordered data types, this will create an intuitive ordering,
> and not require an error to be raised. For example, with the source:
> 
>   <relationship length="P1M">...</relationship>
>   <relationship length="P21D">...</relationship>
>   <relationship length="P5Y1D">...</relationship>
>   <relationship length="P28D">...</relationship>
>   <relationship length="P3M">...</relationship>
> 
> it would be possible to sort them with:
> 
>   <xsl:for-each select="relationship">
>     <xsl:sort select="@length" data-type="xs:duration" />
>     <xsl:copy-of select="." />
>   </xsl:for-each>
> 
> in order to get:
> 
>   <relationship length="P21D">...</relationship>
>   <relationship length="P1M">...</relationship>
>   <relationship length="P28D">...</relationship>
>   <relationship length="P3M">...</relationship>
>   <relationship length="P5Y1D">...</relationship>
> 
> without getting an error of any kind.
> 
> Cheers,
> 
> Jeni
> ---
> Jeni Tennison
> http://www.jenitennison.com/
>

Received on Thursday, 9 May 2002 13:02:39 UTC