Re: [Json] JSON and int64s - any change in current best practice since I-JSON

[Joe Hildebrand <[e-mail]>]

> On Jan 25, 2024, at 7:50 AM, Carsten Bormann <[e-mail]> wrote:
> 
> * parsing bare words as text string map keys can probably be added to EDN with limited pain (triggered on the trailing “:”).  The document currently uses ID_Start/ID_Continue as the repertoires, shouldn’t this be XID_Start/XID_Continue at this point?

Yes.  For anyone else interested, see here: https://www.unicode.org/reports/tr31/#NFKC_Modifications

This is not the place for my rant on how NFD is probably better for most modern protocols than NFKC -- that probably belongs in the CDE thread if anywhere. :)

> * while trailing commas are allowed in EDN, elidable commas conflicts with the string concatenation syntax in Appendix G.4 of RFC 8610.  This is not very widely deployed, so we *could* decide to repeal it.

I don't think it's worth losing a feature for.

> * leading/trailing decimal points.  What is the semantics that need to be defined here?

For leading, probably none.  For trailing, it might be a sign that the number should be treated as floating point, so that there is a difference between `1` and `1.` in environments where there are different types for float and int.  At the very list, the range checking should be different.

> * There are at least 4 kinds of base64 (classic/URL x padding/no); of course only base64URL without padding should be used in JSON, but this probably needs to be said.

Agree.

> * Rejecting duplicate/equivalent keys is probably something we want to put in.

Agree.

— 
Joe Hildebrand