W3C home > Mailing lists > Public > www-tag@w3.org > November 2013

Re: [Json] Consensus on JSON-text (WAS: JSON: remove gap between Ecma-404 and IETF draft)

From: Carsten Bormann <cabo@tzi.org>
Date: Thu, 28 Nov 2013 09:41:04 +0100
Cc: Tim Bray <tbray@textuality.com>, "Matt Miller (mamille2)" <mamille2@cisco.com>, JSON WG <json@ietf.org>, IETF Discussion <ietf@ietf.org>, "www-tag@w3.org" <www-tag@w3.org>, es-discuss <es-discuss@mozilla.org>
Message-Id: <558DF938-2B50-45B0-9696-03D9B9F98690@tzi.org>
To: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>
On 28 Nov 2013, at 08:44, Joe Hildebrand (jhildebr) <jhildebr@cisco.com> wrote:

>> JSON-text  = value
> 
> We also need to make an explicit decision about whitespace-tolerance.

If the point is to track the changes made by ECMA-404 that decision has been made for us (see end of section 4 in 404).
(Note also that JSON is whitespace-tolerant today, so not having that for the new non-containers at top-levels but everywhere else would be rather surprising.*)

Minimal change appears to be:

JSON-text = ws value ws

Gre, Carsten

*) The other interesting practical usage here is removing newlines from the allowed whitespace for a single JSON-text and joining sequences of these by newlines to form streams of JSON values.
But that is outside the scope of application/json and application/__+json, an instance of which is exactly one JSON-text.
(truenull3true is a valid stream of JSON texts if you dont require adding whitespace as delimiters.
Implementations that employ a typical form of tokenization without knowing what those tokens can be in JSON wont like that.  In any case, whitespace is needed to separate numbers.)
Received on Thursday, 28 November 2013 08:41:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:00 UTC