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

[Carsten Bormann <[e-mail]>]

On 2024-01-23, at 00:54, Joe Hildebrand <[e-mail]> wrote:
> 
> I put together a quick requirements doc: https://github.com/hildjj/draft-hildebrand-eson-requirements

Thanks!

I reviewed this with the objective not to miss any simple things we could add to CBOR Extended Diagnostic Notation (EDN) now without creating pain.

I have the following observations (not commenting on the things already in EDN):

* EDN has a simplified comment syntax that accepts most JS-style comments, with some exceptions.  Since this is widely used in RFCs, we probably don’t want to change anything here.  We could detect * characters lining the inside of comments and react differently to embedded slashes though — this would change the meaning of some EDN that is valid today.

* 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?

* 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.

* Detecting range errors (outside binary64) does make sense.  Integers of course have a much larger range in CBOR, so some of this detection would only happen at the point in ingestion where the actual JSON data model is enforced.
(This reminds us that EDN doesn’t have any support for tag 4/5.)

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

* 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.

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

I will make a few PRs for EDN now with the obvious parts...

Grüße, Carsten