LEXICOGRAPHICAL property order is under-specified

[jansupol]

Or to be more correct; if the lexicographical sorting order is going to be of any utility* it could benefit by a more detailed definition. Here is an attempt creating such:
https://cyberphone.github.io/doc/security/draft-rundgren-json-canonicalization-scheme.html#json.sorting.properties

In my Java-based JSON tools I use

for (String property : canonicalized ? new TreeSet<String>(object.properties.keySet()) : object.properties.keySet()) {

which complies with the specification above. Presumably your RI does that as well, right?

*) It is not very clear what the purpose is with this mode. ECMAScript has an entirely different default property ordering mode which is based on the fairly simple idea that declaration/parsing order has a meaning which makes sense for objects like:

{
  "name": "John Doe",
  "address": "2000 Sunset Boulevard",
  "city": "Los Angeles",
  "zip": "90001",
  "state": "CA"
}

Using lexicographical ordering it would be serialized in the order "address", "city", "name", "state" and "zip", which adds fuzziness to the data from a human (developer or technical support), perspective.

[jansupol]

@cyberphone Commented
A little test of mine seems to verify that we are indeed using the same sorting algorithm:

public class Dog {
   @JsonbProperty("\u0080")
   public String name;

   @JsonbProperty("\ufb33")
   public int age;

   @JsonbProperty("\ud83d\ude02")
   public long ijsonlong;

    @JsonbProperty("\u00f6")
    public boolean bitable;
}

Serializes as:
{"□":"Falco","ö":false,"😂":9223372036854775807,"דּ": 4}

The Hebrew letter property comes out a bit strange in HTML...

[jansupol]

@cyberphone Commented
You may wonder what the purpose is, right?

Current standard for signed JSON:
https://openid.net/specs/openid-financial-api-part-2.html#request

eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiA
(... abbreviated for brevity ...)
zCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw

JSON clear text signature alternatives depend on canonicalization:

{
  "id": "johndoe",
  "counter": 3,
  "list": [
    "yes",
    "no"
  ],
  "signature": {
    "alg": "HS256",
    "kid": "mykey",
    "val": "rlKLoCBExrwB7NaChPtQ3cAxr83eGdpLA7txrg49slw"
  }
}

End of Base64 tyranny 😂!!!

[jansupol]

@rmannibucau Commented
+1, it should specify it does a string.compareTo or equivalent.

[jansupol]

@m0mus Commented
compareTo is a proper comparison method in Java. Do you really think that we should go so deep in the spec? Sorry, but it sound like next time you will want us to specify that equals method must be used instead of ==. :)

[jansupol]

@rmannibucau Commented
Rephrase it if you want, i agree it is not a good phrasing. Point was to explicit that 1_foo, 11_nd, 2_xx will be sorted by a straiggt comparison on chars and explain the not iso chars handling too.

[jansupol]

@cyberphone Commented
As you may have noted, I'm working on a scheme for JSON canonicalization. For that particular purpose you need a well defined sorting method and I didn't find any in the JSON-B spec which is why I raised this issue. Fortunately (for me...) the implicit sorting method is compliant with the one I propose. I could imagine adding a reference to String.compareTo() if the JSON-B spec is revised.

[jansupol]

• Issue Imported From: https://github.com/javaee/jsonb-spec/issues/81
• Original Issue Raised By:@cyberphone
• Original Issue Assigned To: Unassigned