W3C home > Mailing lists > Public > public-qt-comments@w3.org > September 2016

[Bug 29722] [FO31] fn:sort, array:sort

From: <bugzilla@jessica.w3.org>
Date: Thu, 08 Sep 2016 12:11:37 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29722-523-mK3Y1ABEYU@http.www.w3.org/Bugs/Public/>

Botond BirĂ³ <botond23@gmail.com> changed:

           What    |Removed                     |Added
                 CC|                            |botond23@gmail.com

--- Comment #7 from Botond BirĂ³ <botond23@gmail.com> ---
(In reply to Michael Kay from comment #6)
> The spec has been updated.

As of 6th of September the array:sort#2 function signature seems to be broken:
array:sort($array as item()*, $collation as xs:string?) as item()*
The type of the first argument and the return type should be array(*)
Should I open a separate bug for this?

Additionally I would suggest some changes in the signatures of the sort
functions (in case they are not carved in stone yet) - namely to move back the
$key in the 2nd position and add the $collation as last argument with the
occurrence exactly one.

fn:sort($input) // same as sort#3($input, fn:data#1, default-collation())

fn:sort($input, $key as function(*)) // same as sort#3($input, $key,

fn:sort($input, $key as function(*), $collation as xs:string) //note the
occurrence on collation type is exactly one

1. In most (if not all) other functions accepting a collation string, it is
added as last in the argument list (ex. fn:compare, fn:contains-token, etc.)
Having them similarly in the sort functions would be a bit more consistent.
2. with the signatures suggested above one could avoid
incompatibilities(err:XPTY0004) with expressions relying on previous spec
3. I think that specifying a different key function is more likely than
switching only to a different collation - but maybe this is my personal
preference/use case only

If you think it's worth considering, please reopen the bug.

Thank you,

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Thursday, 8 September 2016 12:12:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:58:02 UTC