Re: [xslt] xsl:sort again

[Daniel Veillard <veillard redhat com>]

On Fri, Jun 07, 2002 at 10:00:32AM +0200, Raymond Wiker wrote:
> k_isdale@tpg.com.au writes:
>  > Hi all,
>  > 
>  > Is it possible to define an API that knows how to 
>  > compare unicode or at least simpler subsets of it 
>  > and still maintain the orginal sorting order of 
>  > language used? A possible solution would involve 
>  > converting the each unicode character to simpler 
>  > range within unicode. This would be an expensive 
>  > operation I'm sure. For example
>  >   "très" gets converted to "tres"
>  > But at least it would be possible.
> 
>         I think that the iso8859-1 character set (and possibly others
> in that group) maintain correct sorting order within a particular
> locale. So, if iso8859-1 is an acceptable subset, all you need to do
> is to convert from utf-8 to iso8859-1, and do the sorting on that.

  The problem, is that I *absolutely* don't want to resort on the
locale mechanism to implement functionalities in libxslt. This is
plain broken, makes debugging close to impossible, and portability 
an absolute hell. Moreover locale are usually implemented on a process
wide basis and this is not the right level of granularity for the selection
of teh sort model (there are significant usage of the library in
multithreaded apps and running 2 stylsheets in paralllel without breaking
the semantic of the operation is an absolute requirement).

>         Further, I think that you can use strcoll() to sort strings so
> that "très" and "tres" are treated as identical.

  ENOTWORKING :-\

This mean that libxslt may have to duplicate some code already present in the
libc of some platforms, well too bad the API is unusable, after all it's
already the kind of option taken when deciding to embed trio in libxml2.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/