- From: Liam R. E. Quin <liam@fromoldbooks.org>
- Date: Thu, 14 Mar 2024 20:44:11 -0400
- To: "public-xslt-40@w3.org" <public-xslt-40@w3.org>
On Thu, 2024-03-14 at 11:50 -0700, Dimitre Novatchev wrote:
> > I see; so in a nutshell it’s this?
> >
> > sort(
> > $input,
> > keys := fn { string-to-codepoints(.) ! (0x110000 - .),
> > 0x110000 }
> > )
>
is this for a spec or are users expected to do this?
People spend a lot of time making sort routines performant... a key
comparison routine makes it easy to find online examples and sort
descending, and decide where you want empty string to so, at the
expense of slightly more CPU (e.g. n log n function calls instead of n
function calls storing n surrogate keys). But if the key constructor is
itself doing a lot of work, the comparison function approach will win
until log n is large enough to start to lost out. By that point the
additional memory management of storing the keys may become
significant. I suppose this could be tested.
I’d rather see an
fn:sort2($input as item()*, $options as map(*)) as item()*
where options can include a comparison function or a key consutrctor, a
collation, a direction, and whether empty sequences / empty strings go
at start or end, rather like SQL's join syntax.
--
Liam Quin, https://www.delightfulcomputing.com/
Available for XML/Document/Information Architecture/XSLT/
XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
Barefoot Web-slave, antique illustrations: http://www.fromoldbooks.org
Received on Friday, 15 March 2024 00:44:37 UTC