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

Carsten Bormann <> Fri, 26 January 2024 22:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1DF83C14CF01; Fri, 26 Jan 2024 14:55:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6qzlD7Tpub2y; Fri, 26 Jan 2024 14:55:12 -0800 (PST)
Received: from ( [IPv6:2001:638:708:32::21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id C3956C14F71C; Fri, 26 Jan 2024 14:55:11 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4TMChF1G9MzDCbP; Fri, 26 Jan 2024 23:55:09 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Fri, 26 Jan 2024 23:54:58 +0100
Cc: "" <>,, Tim Bray <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Joe Hildebrand <>
X-Mailer: Apple Mail (2.3774.400.31)
Archived-At: <>
Subject: Re: [Json] JSON and int64s - any change in current best practice since I-JSON
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Jan 2024 22:55:15 -0000

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