Subject: RE: multiple sorting From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx> Date: Wed, 16 Aug 2000 23:21:25 +0100 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: multiple sorting, David_Marston | Thread | Re: multiple sorting, Jeni Tennison |
RE: Using tags within tags, David Allouche | Date | Check if XML tag exists?, David C Petite |
Month |