How does array:sort work for an array of element nodes?

[martin-honnen]

I am surprised by the result of the query array { //tip } => array:sort() in the playground:

Array with 3 items:<tip id="edit">You can edit everything on the left</tip><tip id="examples">You can access more examples from a menu in the top right</tip><tip id="permalink">Another button there lets you share your test using an URL</tip>

Should the result not be

Array with 3 items:<tip id="permalink">Another button there lets you share your test using an URL</tip><tip id="examples">You can access more examples from a menu in the top right</tip><tip id="edit">You can edit everything on the left</tip>

?

Or how does array:sort in FontoXPath work?

[martin-honnen]

I would think untyped element nodes should be sorted by their typed value which would be an xs:untypedAtomic.

FontoXPath for e.g. array { data(//tip) } => array:sort() gives me the expected order (Array with 3 items:"Another button there lets you share your test using an URL""You can access more examples from a menu in the top right""You can edit everything on the left"), as for array { //tip/xs:untypedAtomic(.)) } => array:sort().

Not sure why the array of element nodes in the array are not sorted in the same order as their data or typed values.

[bwrrp]

Hi!

That looks like a bug. From the code it appears we're not currently applying fn:data as the default key function and only sort primitive values correctly.

[DrRataplan]

Correct, offending code is around here: https://github.com/FontoXML/fontoxpath/blob/master/src/expressions/functions/builtInFunctions_arrays.ts#L441

Before passing anything to that deeplessthan we should pass it through atomize. Would be nice to do this atomization only once per item though, and possibly make implement the array:sort#3 alias with a custom key function in one go.

@bwrrp would you have time to implement this some time?

Kind regards,

Martin

[bwrrp]

Not in the short term I'm afraid, but I'll put it on the list 😅

Wouldn't implementing the overload that accepts key also require accepting collation? We don't really have any collation support yet, but I think we can get away with only accepting a single value (http://www.w3.org/2005/xpath-functions/collation/codepoint I guess?), and then probably also implementing fn:default-collation to return that for convenience?