This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: xsl:sort/@case-order feature missed
- From: "Jonathan Perret" <jonathan at holylabs dot com>
- To: <xsl-list at lists dot mulberrytech dot com>
- Date: Thu, 31 Jan 2002 15:40:41 +0100
- Subject: Re: [xsl] xsl:sort/@case-order feature missed
- References: <68C4F996365AD31190ED00902751CF9C02B1BFAC@INA-DE0104.ina.de>
- Reply-to: xsl-list at lists dot mulberrytech dot com
I only have the first edition of the XSLT programmer's reference,
so maybe this has changed, but mine says for the meaning
of case-order :
"Defines whether upper-case letters are to be collated before
or after lower-case letters. The default is language-dependant."
The language that is referred to here can only be the one that
is specified by xsl:sort's lang attribute, given that it seems
hard to define what happens when sorting elements that
bear different xml:lang attributes.
So if you don't specify case-order, you should get either the
upper-first or the lower-first behavior, depending on the
lang attribute. I think that's what "case-order effective value"
means. There does not seem to be a way to sort in
document-order strings that only differ in case.
In fact, to achieve what you want, the processor would have
to compare strings in a case-insensitive way, which is
somewhat different from deciding whether uppercase
comes before or after lowercase. I'm not sure this behavior
should be considered a variant of case-order.
If there was an uppercase() function (is there one in XSLT 2 ?)
this would get you the desired order :
<xsl:sort select="uppercase(...)" />
In short, getting rid of the case-order attribute will not be
useful. You'll get the default case-order for your
processing environment's default language.
Cheers,
--Jonathan
PS: I don't quite understand your point 2.
Do you mean that my previous suggestion would not work in
your application ? Notice that I carefully did not write such
thing as :
<xsl:choose>
<xsl:when test="...">
<xsl:sort ...>
</xsl:when>
Perhaps if we could see more of the templates in question
it would be easier to help.
In any case, the point is moot if as I surmise above, the
absence of case-order does not give your intended result.
----- Original Message -----
From: "Nestel, Frank ISC 6" <nestefan@de.ina.com>
To: <xsl-list@lists.mulberrytech.com>
Sent: Thursday, January 31, 2002 2:51 PM
Subject: AW: [xsl] xsl:sort/@case-order feature missed
>
> Thanks Jonathan for your reply.
>
> I'm not sure if I understand your suggestions. Well, maybe
> I understand but didn't like what you meant :-)
>
> 1. When it comes to our application, I could use something
> like "sort, but use document order as tiebreak" instead of
> specifying a case order explicitely or implicitely (by
> some default). If this order does not exist, I could use
> it. Maybe we have to create an extra sort attribute or so.
> But this is ugly. As I understand Michael Kay in his book,
> he claimes that case order depends on the actual publication,
> not only on language. What depends on language is the way
> the letters themselves are collated (he gives an example
> about the rules for German/Swedish ä ) In my eyes the
> XSLT standard of w3c is not entirely explicit in this respect.
> But this might be my lacking sense of fine grained English.
> In XSLT 2 it all depends how to read "case-order effective value"
> in the situation where no case-order is present. I didn't understand
> yet the new collation attribute in XSLT 2 and whether this could
> provide a solution to my problem:
>
> 2. Of course one could keep two sort statements. The problem
> I had only arrose, cause we had a stack of named templates
> which were all them same, but differed in that little case-ordering,
> so duplication does not only involve duplication of two simple
> xsl:sort elements but restructuring and duplication of some part
> of a template call hierarchy. We just wanted to avoid that sheer
> uglyness. Unfortunately there is no way of doing s.th. like
> <xsl:choose>
> <xsl:when test="...">
> <xsl:sort ...>
> </xsl:when>
> ...
> </xsl:choose>
> Such a control probably hurt the possibilty to avoid some
> runtime work by smart preprocessing of the stylesheet on
> first translation.
>
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list