diff --git a/specifications/xslt-40/src/xslt.xml b/specifications/xslt-40/src/xslt.xml index bc7681d6e..ad63a5942 100644 --- a/specifications/xslt-40/src/xslt.xml +++ b/specifications/xslt-40/src/xslt.xml @@ -22940,6 +22940,15 @@ return if ($i le count($S)) Comparing Sort Key Values + + + Numeric values of type xs:decimal are compared + as decimals, without first converting to xs:double. + + + Composite sort keys are allowed in xsl:sort. + +

It is possible to force the system to compare sort key values using the rules for a particular datatype by including a cast as part of the sort key component. For example, <xsl:sort @@ -22966,30 +22975,64 @@ return if ($i le count($S)) the xsl:sort element has a value other than text or number, the effect is implementation-defined.

- -

If any sort key value, after + If the xsl:sort element is processed with XSLT 1.0 + behavior, + then if any sort key value, after atomization and any type conversion required by the data-type - attribute, is a sequence containing more than one item, then the effect - depends on whether the xsl:sort element is processed with XSLT 1.0 - behavior. With XSLT 1.0 behavior, the effective - sort key value is the first item in the sequence. In other cases, this is a - type error.

- -

-

The set of sort key values (after any - conversion) is first divided into two categories: empty values, and ordinary - values. The empty sort key values represent those items where the sort key value - is an empty sequence. These values are considered for sorting purposes to be equal - to each other, but less than any other value. The remaining values are classified - as ordinary values.

+ attribute, is a sequence containing more than one item, then the effective + sort key value is the first item in the sequence.

+ +

In general the sort key values (after any + conversion) are sequences of atomic items. Two sequences of atomic items + S1 and S2 are compared as follows:

+ + +

If both S1 and S2 are empty sequences, + then they compare equal.

 +

A sequence that is empty is considered to be less than + a sequence that is not empty.

 +

If neither sequence is empty, then + head(S1) and + head(S2) are compared + according to the rules below.

+ +

If they compare equal, the result is obtained + by comparing tail(S1) to + tail(S2).

 +

Otherwise, the result of comparing these two + items is used as the result of the sequence comparison.

 + + +

For example:

+ +

(1, 2, 3) precedes (1, 2, 4).

 +

(1, 2) precedes (1, 2, 3)

 +

() precedes (1, 2)

 + +

Individual atomic items are compared as follows:

+ +

If both values are instances of xs:string, xs:anyURI, + or xs:untypedAtomic, they are compared using the appropriate collation, + as described in the next section.

 +

If both values are instances of xs:numeric, they are compared + using the compare function.

+

This is a change from earlier versions, since xs:decimal values are now compared + as decimals, rather than being first converted to xs:double.

 +

In all other cases, values are compared according to the rules + of the XPath lt operator. This will raise an error if the values are + not comparable (for example, if one is an xs:integer and the other is + an xs:date).

 + + +

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 + of atomic items 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 raise it as a static @@ -23009,20 +23052,7 @@ return if ($i le count($S)) the corresponding major sort key values are equal.

-

Individual values are compared as follows:

- -

If both values are instances of xs:string, xs:anyURI, - or xs:untypedAtomic, they are compared using the appropriate collation, - as described in the next section.

 -

If both values are instances of xs:numeric, they are compared - using the compare function.

-

This is a change from earlier versions, since xs:decimal values are now compared - as decimals, rather than being first converted to xs:double.

 -

In all other cases, values are compared according to the rules - of the XPath lt operator. This will raise an error if the values are - not comparable (for example, if one is an xs:integer and the other is - an xs:date).

 - +