This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 1753 - The sorting process
Summary: The sorting process
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 2.0 (show other bugs)
Version: Last Call drafts
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-07-19 19:07 UTC by Joanne Tong
Modified: 2005-07-28 21:37 UTC (History)
0 users

See Also:


Attachments

Description Joanne Tong 2005-07-19 19:07:01 UTC
According to section 13.1.1 (The Sorting Process) of the XSLT 2.0 spec, sorting 
is done pairwise for comparable types.  The following stylesheet and input 
document illustrate why comparing values in pairs contradict with other 
requirements.

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0">
  <xsl:output method="text"/>
  <xsl:template match="/">
    <xsl:for-each select="doc/e">
      <xsl:sort select="xs:float(@f),xs:integer(@i)" stable="yes"/>
      <xsl:value-of select="."/>
    </xsl:for-each>
  </xsl:template>
</xsl:stylesheet>

<doc>
  <e i="100000001">v1</e>
  <e f="100000000.0">v2</e>
  <e i="100000000">v3</e>
</doc>

     The sort key for the first element is the xs:integer value 100000001, for 
the second is the xs:float value 100000000.0 and for the third is the 
xs:integer value 100000000.  The sort keys for the first and third elements 
compare equal to the sort key for the second element, and the sort key 
specification is stable, so the first element must precede the second in the 
sorted sequence and the second must precede the third in the sorted sequence.  
However, the sort key for the third element is less than the sort key for the 
first element, so the third element must precede the first in the sorted 
sequence.

A possible solution to this problem is to align sorting with XQuery's order by:

The third bullet of section 3.8.3 (Order By and Return Clauses) of the XQuery 
spec says:

All the non-empty orderspec values must be convertible to a common type by 
subtype substitution and/or type promotion. The ordering is performed in the 
least common type that has a gt operator.

thanks,

Joanne
Comment 1 Sharon Adler 2005-07-28 19:38:06 UTC
Since the WG accepted this at the Redmond f2f Michael Kay should close when he
has applied the change to the document.
Comment 2 Michael Kay 2005-07-28 21:37:44 UTC
Change now applied to the editor's draft. The relevant para now reads (changes
marked at="Y"):

<p>In general, comparison of two ordinary values is
 performed according to the rules of the
 XPath <code>lt</code> operator. <phrase diff="add" at="Y">To ensure a total
ordering, the same 
 implementation of the
 <code>lt</code> operator <rfc2119>must</rfc2119> be used for all the
comparisons: the one that is chosen
 is the one appropriate to the most specific type to which all the values can be
converted by subtype substitution
 and/or type promotion. For example, if the sequence contains both
<code>xs:decimal</code> and <code>xs:double</code>
 values, then the values are compared using <code>xs:double</code> comparison,
even when comparing two
 <code>xs:decimal</code> values.</phrase> 
 NaN values, for sorting purposes, are considered to be equal to each other,
 and less than any other numeric value. Special rules
  also apply to the <code>xs:string</code> type
  and types derived by restriction from <code>xs:string</code>,
  as described in the next section.</p>