DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1396>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1396 XSLTC does not handle case-order attribute of xsl:sort [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[EMAIL PROTECTED], | |[EMAIL PROTECTED] | |.com AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] Status|REOPENED |NEW ------- Additional Comments From [EMAIL PROTECTED] 2004-02-08 21:42 ------- It is not trivial to implement truly international friendly case-order. Code above (which mentioned as Saxon's one) has some limitations. 1. As far as I understood it is only for Latin-1 characters. 2. It ignores the facts that (see http://www.unicode.org/reports/tr21/tr21-5.html) a. Characters may have case mappings that depend on the locale. b. Characters may also have different case mappings, depending on the context. d. Case mappings may produce strings of different length than the original. There are some other limitations. ICU for java (see http://oss.software.ibm.com/icu4j/) has an implementation based on inserting 2 case bits in a collation element between secondary tertiary weight levels. This implementation is fast and has really good coverage in terms of languages, special cases and so on. I am not really sure that it is really practical to have dependences on ICU jars just to implement case-order. We could think about using ICU for 2.0 functionality to implement:, normalize-Unicode, language-aware string search, xsl:number element (attribute "ordinal" and tokens w, W and Ww) and Calendar. I think that the reasonable solution for 1.0 processor would be to implement case-order based on JDK CollationElement functionality. It would be slower than ICU based solution, but much less limited than Code above (which mentioned as Saxon's one). I am assigning this defect to myself and will implement JDK based functionality unless somebody would have any objections. Case-order has L3 (tertiary) weight. If case-order attribute was specified, then case differences are significant (even if strength is less than tertiary). All L1 or L2 weight differences are more significant than case-order. The case differences are more significant than all other tertiary ones. The processor is not required to distinguish between title and upper case. Rules for mixed-case collation elements are not specified.
