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

[Bret Jordan <[e-mail]>]

I fully agree Jim


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 17, 2019, at 10:56 PM, Jim Schaad <[e-mail]> wrote:
> 
> +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
>>