- From: <bugzilla@jessica.w3.org>
- Date: Thu, 08 Sep 2016 12:11:37 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29722
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,
default-collation())
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
implementations
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