Re: [Json-canon] Dropping "Comparable" JSON

[Jim Schaad <[e-mail]>]

+1

 

What I care about here is JSON – there are a limited number of data types for JSON.  I don’t care about trying to shove other JavaScript types or C++ types into JSON strings.

 

Jim

 

 

From: json-canon <[e-mail]> On Behalf Of Bret Jordan
Sent: Wednesday, February 13, 2019 1:22 PM
To: Carsten Bormann <[e-mail]>
Cc: Samuel Erdtman <[e-mail]>; [e-mail]; Anders Rundgren <[e-mail]>
Subject: Re: [Json-canon] Dropping "Comparable" JSON

 

I am not sure I understand what you are proposing or what changes you would like.   I personally think that JCS should focus on a very limited and narrow set of use cases.  We should address how to represent JSON in a canonical form, period.  What people do with it beyond that is out-of-scope.

 

Thanks,

Bret

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."





On Feb 12, 2019, at 10:02 AM, Carsten Bormann <[e-mail] <mailto:[e-mail]> > wrote:

 

On Feb 9, 2019, at 08:05, Anders Rundgren <[e-mail] <mailto:[e-mail]> > wrote:




I begin to wonder if "Comparable" JSON (in the draft named "true" canonicalization) shouldn't be a "Feature at Risk" as the W3C folks call this.


Well, first of all, there is no “feature” here — the current draft just points out that deterministic encoding (“canonicalization”) reaches up to the application using JSON wherever that does its own encoding work.

That is a fact that is good to know, but nothing is contributed to interoperability by this document.

To do so, one would need a way to describe elements of the application data model and constrain the application data encoding decisions made on the way to the JSON data model.  We don’t have a good way to do this at the moment (even if the document misleadingly mentions the “schema” word).

Actually, the document about deterministic encoding of JSON (your “Hashable” thing — I still have no idea where these confused terms came from) could be stating this fact, if only as a matter of delineating what is *not* being defined in that document.

The document currently does not say how it was intended to be developed further.  As it stands, it is indeed of little use.  Collecting a set of preferred application-data-model to JSON-data-model encoding decisions, however, might be a useful undertaking, somewhat unrelated to the constraints on serializing the JSON data model that the other document wants to define, and probably on a much longer time scale.

Grüße, Carsten