Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values)

Larry Masinter <> Thu, 13 March 2014 21:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2AAC61A0A47 for <>; Thu, 13 Mar 2014 14:44:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Wn8CurqDgSah for <>; Thu, 13 Mar 2014 14:44:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E5A171A0778 for <>; Thu, 13 Mar 2014 14:44:48 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.893.10; Thu, 13 Mar 2014 21:44:39 +0000
Received: from ([]) by ([]) with mapi id 15.00.0893.001; Thu, 13 Mar 2014 21:44:39 +0000
From: Larry Masinter <>
To: Matthew Morley <>, Nico Williams <>
Thread-Topic: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values)
Date: Thu, 13 Mar 2014 21:44:38 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-forefront-prvs: 01494FA7F7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(428001)(199002)(189002)(377454003)(24454002)(51704005)(74876001)(74502001)(46102001)(47446002)(4396001)(87266001)(74316001)(65816001)(54356001)(85306002)(56776001)(53806001)(80022001)(51856001)(69226001)(66066001)(74706001)(19300405004)(74366001)(76796001)(76786001)(47736001)(2656002)(50986001)(80976001)(85852003)(19580405001)(83072002)(19580395003)(76576001)(97336001)(79102001)(94946001)(59766001)(77982001)(97186001)(83322001)(92566001)(93136001)(33646001)(81342001)(56816005)(63696002)(95416001)(90146001)(15202345003)(31966008)(15975445006)(16236675002)(76482001)(49866001)(47976001)(86362001)(81686001)(95666003)(93516002)(81542001)(81816001)(74662001)(87936001)(94316002)(24736002)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR02MB308;; CLIP:; FPR:C867F454.A6E1F409.71DF7177.40A5F1F1.20431; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (: does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_664149bc6d3941afad86684fac806a17BL2PR02MB307namprd02pro_"
MIME-Version: 1.0
Cc: Phillip Hallam-Baker <>, Tim Bray <>, Paul Hoffman <>, "" <>
Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values)
X-Mailman-Version: 2.1.15
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: Thu, 13 Mar 2014 21:44:54 -0000

I think most of i-json and also this discussion on JSON sequences would fit into a "guidelines" document. "Guidelines for use of JSON in Internet protocols".
Then it could be BCP, could cover \u2028 \u2029, string length limits, floating point, separators in sequences, and other advice.

much more straightforward. It could even cover "JSON vs alternatives" and pros and cons comparison to XML, CBOR, ASN.1 and whatever.

From: json [] On Behalf Of Matthew Morley
Sent: Tuesday, March 11, 2014 11:27 AM
To: Nico Williams
Cc: Tim Bray; Phillip Hallam-Baker; Paul Hoffman;
Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values)

I'm not advocating for comma separators...

But having multiple top level JSON elements separated by a coma is equivalent to processing an array structure. The initial [ and the closing ] are implicitly mapped to the connection/stream/etc. start and end events.

It is just a minor token replacement at the top level between elements, which could be layered into some existing tooling. From this point of view, I would imagine the retooling is minor for either use case. It does mean tools need to be depth aware.

On Tue, Mar 11, 2014 at 2:08 PM, Nico Williams <<>> wrote:
On Tue, Mar 11, 2014 at 12:09 PM, Phillip Hallam-Baker <<>> wrote:
> On Tue, Mar 11, 2014 at 12:48 PM, Tim Bray <<>> wrote:
>> Heh, I wonder if there'd be any chance of getting consensus.  I can't
>> imagine ever using anything but Object Object Object with optional
>> whitespace separator; unless we all agree on that going in I'd pessimistic
>> about anyone convincing anyone else...
> But JSON has comma separators, so {..}, {..}, {..} makes far more sense.
JSON text sequences would be a new Proposed Standard (if we go there)
but like JSON, there exist uses of this "new" thing already -- that
is, before we get to writing the RFC.

The uses of JSON text sequences that I know of use newlines, not
commas nor comma-and-newline.  The reason for this is that these use
cases are text logfile-like: the entries are lines, lines containing
JSON texts -- usually compact texts, i.e., with no newlines in the
text, and never more than one text per-line.

For me other uses of JSON text sequences generally result from my use
of jq, which also effectively separates texts with a newline.  Note
that jq doesn't need texts to be written compactly when parsing JSON
text sequences.  It happens though that if you write texts compactly
followed by a newline then you can implement JSON text sequences with
all existing JSON parsers.

Switching to using a comma-and-newline would require significant
retooling.  Therefore I don't see it happening.  Whereas just
separating JSON texts with newlines is in use because it's always been
the obvious thing to do.


Matthew P. C. Morley