Comparing the bytes of UTF-8 works out the same as comparing codepoints, conveniently. So I’d suggest defining the ordering that way.

I think this is true most of the times, but there seem to be corner cases described by,

`Many people expect the characters in their language to be in the "correct" order in the Unicode code charts. Because collation varies by language and not just by script, it is not possible to arrange the encoding for characters so that simple binary string comparison produces the desired collation order for all languages`

a bit weird considering the "`[]`

sort before `[null]`

", where there isn’t a “counterpart” against which to compare.

Good point. I will add this detail to the proposal:

- Length of the array shall not be considered by the comparator logic.
- And empty array shall sort before non empty arrays.

You should explicitly mention negative zeros, and whether you’re making a total order or not.

Yes the idea is to make a total ordering for the combined set of Integer and Float.

- f64 values that are <= -2^127 will sort before all i128 integers.
- f64 values that are >= 2^127-1 will sort after all i128 integers.
- NaN, Not a Number values shall sort after all i128 integers.
- -Infinity shall sort before all numbers.
- +Infinity shall sort after all numbers.
- NaN shall sort after +Infinity.

Additionally I will amend proposal with

- f64 Negative ZERO shall short before f64 Positive ZERO.

I’m not sure you need to include these in JSON; you can have them be external, like Bound::Unbounded.

Excellent. To begin with, unboundedness are never part of any sorted set

of values. They just come from query. Will amend the proposal and code.