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

[Carsten Bormann <[e-mail]>]

On Jan 25, 2024, at 15:50, 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?

Two items of pain:

* ABNF doesn’t have access to the Unicode character database (well, that wasn’t around in 1976).
So this would be hard to specify in EDN without extending ABNF first (or using the prose construct, which would make the ABNF much less useful).  Of course, we would get 80 % of the gain by limiting this to [A-Za-z_][A-Za-z0-9_]* only...

* More importantly: false, null, true, undefined, Infinity, NaN can occur in CBOR as map keys; we’d need to forbid these as barewords (which won’t seem logical to a JSON-only world (*)) or do something else unhealthy.

So it seems to me this feature cannot easily be added to EDN (**).
(CDDL does have bareword keys, at the cost of requiring => instead of : for keys that are not strings or numbers.)

Grüße, Carsten

(*) Slight deja vu: IIRC, the reason the final version of JSON has quotes around map keys when JavaScript didn’t need them was that a JSON implementation would need to know the current set of JavaScript keywords in order not to set off syntax errors in eval().  Exercise for the reader: find the original citation for that...

(**) An unambiguous half-barewords variant with at least somewhat reduced noise:

{
  :lat: 53,
  :lon: 8,
}

Too innovative, probably.