You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by bu...@apache.org on 2004/02/08 22:42:59 UTC
DO NOT REPLY [Bug 1396] -
XSLTC does not handle case-order attribute of xsl:sort
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
igorh@ca.ibm.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |xalan-dev@xml.apache.org,
| |Santiago.PericasGeertsen@sun
| |.com
AssignedTo|xalan-dev@xml.apache.org |igorh@ca.ibm.com
Status|REOPENED |NEW
------- Additional Comments From igorh@ca.ibm.com 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.