Re: [xslt] XSL Sort + ICU

Hi again

One more quick question -
I've made all the changes required to make xsltDoSortFunction() pluggable,
but have hit a small snag trying to write my replacement ICU version.

The existing xlstDoSortFunction() calls xsltComputeSortResult() twice which
is defined as a static function in xsltutils.c.
I'm not 100% sure what xsltComputeSortResult() does but I'm happy to accept
that it's needed for the sorting. (The comment for it is identical to
xsltDoSortFunction(), and I've tried stepping through it with the debugger
and worked out that it likes sorting the node-set into document order
repeatedly, but not sure what else it is doing).

My question is can I make the function public so the pluggable sort
functions can call it as well, or will they need to have their own copy of
xsltComputeSortResult() ?


----- Original Message -----
From: "Daniel Veillard" <>
To: <>
Sent: Friday, November 22, 2002 5:10 PM
Subject: Re: [xslt] XSL Sort + ICU

> On Fri, Nov 22, 2002 at 04:42:58PM -0000, Richard Jinks wrote:
> > Hi all.
> >
> > I've just started modifying libxslt so that people can plug in the ICU
> > library to handle Unicode / Locale type sorting.
>   Hum, yes this makes sense. Too big to embbed, should allow to be plugged
> > >From what I can tell, the main function that performs the sorting is
> > xsltDoSortFunction() in xsltutils.c.
>  yes
> > The two best ways I can think of modifying this are:
> > 1) Add a #define and have two copies of the function
> > 2) Add an API call to allow users to register their own sort function
> > get xsltDoSortFunction to call it (in a similar manner to the Error
> > routines).
> >
> > The former requires no API changes, and is relatively painless.
> > The second seems more future-proof should someone need a different
method of
> > collating Unicode characters, or have their own optimised sort routine,
> > This method would require a new API function call to let users register
> > new sort routine, and would require somewhere to store the pointer to
> > sort function.
> > Does any one have any preference for either or are aware of anything
> > not taken into account before I start work implementing the second
>   Well I definitely prefer the second one, you know my style :-)
> > Second question is regarding the attributes for lang and case-order.
> > Both the pre-compile and the sort function store the contents of the
> > attributes for the xsl:sort element on the xsltStylePreComp structure.
> > structure doesn't currently contain any variables to store the lang or
> > case-order attributes. Is it safe to add these, or are people's code
> > to be so dependant on this structure that they'll break if it changes?
>   Well people's code really should not be dependant on that, I may
> break that structure at some point because it's too big, each compiled
> only need a few of those fields, so feel free to add, yes, it's not part
> of the official API,
>   thanks,
> Daniel
> --
> Daniel Veillard      | Red Hat Network
>  | libxml GNOME XML XSLT toolkit
> | Rpmfind RPM search engine
> _______________________________________________
> xslt mailing list, project page

Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]