RE: multiple sorting

[Jeni Tennison <mail at jenitennison dot com>]

David,

>I'd also suggest a caution in setting up "futile" sorts,
>which is a key part of the suggested techniques. The XSLT
>spec is clear about how to deal with data that exists but
>compares equal, but the case where the sort key doesn't
>exist is shrouded in indirection. I think that the verbiage
>about how the sort key is evaluated covers the techniques
>presented here, but it gets right to the borderline. If the
>sort key is something that can't be evaluated, then the
>processor could decide not to sort and presumably raise
>an error. If the processor instead presented the nodes in
>their original document order, I can't find anything in
>the spec to prohibit it.

The XSLT Recommendation says:

"xsl:sort has a select attribute whose value is an expression. For each
node to be processed, the expression is evaluated with that node as the
current node and with the complete list of nodes being processed in
unsorted order as the current node list. The resulting object is converted
to a string as if by a call to the string function; this string is used as
the sort key for that node."

In the technique I was advocating, the resulting object of evaluating the
select expression is an empty node list.  I think that an empty node list
is still counted as an object (rather than 'not existing'), and certainly
it says in XPath:

"A node-set is converted to a string by returning the string-value of the
node in the node-set that is first in document order. If the node-set is
empty, an empty string is returned."

which both implies that the empty node-set is an object that can be turned
into a string, and indicates that such a string should be an empty string.

Given that the string will be empty for all the nodes that are being
sorted, then the xsl:sort results in no sorting occuring.

At least that's my interpretation :)

>There is an additional question about where null values
>(like NaN in numeric sorting) are placed. One of the
>techniques has nested sorts, which would be affected by
>this behavior.

Certainly this is something to bear in mind when converting strings to
numbers for sorting (especially as the conversion to strings is implicit).
But in the technique I was describing, *all* the nodes to be sorted
resulted in NaN: I would have thought the sort order should remain
unchanged from the previous sort.

Does that make sense?  Or is the ambiguity that you were referring to about
how to deal with sorting that includes empty strings and NaNs and whether
to accept these as sort keys?  Personally (again), I think it's a lot more
useful if the processor doesn't object to them.

Cheers,

Jeni

Jeni Tennison
http://www.jenitennison.com/


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list