RE: XSLT 2.0: Sorting and indeterminate comparisons

Jeni:
We are trying to get away from indeterminate comparisons.
Our attempt is to deprecate 'duration' and have users use
two totally ordered subtypes of duration called 'yearMonthDuration'
and 'dayTimeDuration'.

For the date/time types we say that for purposes of comparison and
arithmetic all date/time values have an implementation specific timezone
This makes them totally ordered.

Take a look at the latest Functions and Operators document:
http://www.w3.org/TR/xquery-operators/
This does not contain the changes for the date/time datatypes  
mentioned above.  These will appear in the next version.

All the best, Ashok 
===========================================================
Ashok Malhotra              <mailto: ashokma@microsoft.com> 
Microsoft Corporation
212 Hessian Hills Road
Croton-On-Hudson, NY 10520 USA 
Redmond: 425-703-9462                New York: 914-271-6477 



-----Original Message-----
From: Jeni Tennison [mailto:jeni@jenitennison.com] 
Sent: Thursday, May 09, 2002 6:02 AM
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 10:07:49 UTC