Re: [Json] serializing sequences of JSON values

"Paul E. Jones" <> Mon, 10 March 2014 19:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DA5E91A04C2 for <>; Mon, 10 Mar 2014 12:38:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.917
X-Spam-Status: No, score=0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PFioCf1Acxa2 for <>; Mon, 10 Mar 2014 12:38:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EC6691A04BC for <>; Mon, 10 Mar 2014 12:38:09 -0700 (PDT)
Received: from [] ([]) (authenticated bits=0) by (8.14.5/8.14.5) with ESMTP id s2AJZXtw020352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Mar 2014 15:35:34 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=dublin; t=1394480136; bh=nYd9hjXsMO3zxQGoarCb9aKwls60GtuLgC8q5T4SLwM=; h=From:To:Subject:Cc:Date:Content-Type:In-Reply-To:Message-Id: Mime-Version:Reply-To; b=M1TNYqiobQowxfLyVFpM4/zTlmf+T+Y9Uvee+eO2Gp3D/eNSMZ6YbFTRAlQxGZyAg fYRgxUrU/X0fD8F9fc59rNPyze73+TMtwcYCuRomYriU7/4SIrq7DeEc3BOdGIXHsY 16j0vwxHBjBqVmne0t8RUB7ahJODGG5hheA+qXY8=
From: "Paul E. Jones" <>
To: "Phillip Hallam-Baker" <>, "Jacob Davies" <>
Date: Mon, 10 Mar 2014 19:35:34 +0000
Content-Type: multipart/alternative; boundary="------=_MB5EC454FD-3192-4B94-A6B8-35A69536920E"
In-Reply-To: <>
Message-Id: <em2c025504-6532-4513-a339-3d71c4cdfbda@helsinki>
Mime-Version: 1.0
User-Agent: eM_Client/6.0.19861.0
X-Mailman-Approved-At: Mon, 10 Mar 2014 12:38:42 -0700
Cc: Pete Resnick <>, Bjoern Hoehrmann <>, Paul Hoffman <>, Larry Masinter <>, "" <>, Tim Bray <>, "Joe Hildebrand \(jhildebr\)" <>, "Matt Miller \(mamille2\)" <>, Nico Williams <>, Barry Leiba <>, "" <>
Subject: Re: [Json] serializing sequences of JSON values
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: "Paul E. Jones" <>
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Mar 2014 19:38:13 -0000

Why would sequences of objects not be preferred for logging.  If I were 
writing to a log file, that would definitely be my preference.  One 
reason is that log files tend to have a number of pieces of information 
to convey per entry, thus they can fit well into a JSON object (even if 
it is a simple object).


------ Original Message ------
From: "Phillip Hallam-Baker" <>
To: "Jacob Davies" <>
Cc: "Nico Williams" <>om>; "Barry Leiba" 
<>rg>; "Pete Resnick" <>om>; 
"Bjoern Hoehrmann" <>et>; "Paul Hoffman" 
<>rg>; "" <>rg>; "Paul E. 
Jones" <>om>; "Tim Bray" <>om>; "Joe 
Hildebrand (jhildebr)" <>om>; "Matt Miller (mamille2)" 
<>om>; "Larry Masinter" <>om>; 
"" <>
Sent: 3/10/2014 2:47:43 PM
Subject: Re: [Json] serializing sequences of JSON values

>On Mon, Mar 10, 2014 at 2:14 PM, Jacob Davies <> wrote:
>>Does either the old or new specification say anything about multiple
>>values in sequence? I'm pretty darn sure the old version at least said
>>that application/json documents contain one and only one value, and
>>says nothing about serializing JSON in other formats, so encapsulation
>>is not addressed. I also don't see how any process that expects to
>>read sequences of self-delimited JSON objects and arrays is going to
>>blithely accept numbers and strings and whatnot.
>True, but there are multiple ways that sequences can be fashioned and 
>this is a standards organization so we should pick exactly one 
>The log file use case is critical for me. The stupidity of the 
>restriction in XML is tedious enough without repeating it in the JSON 
>world. People want to write append only logs of information. So the 
>sequence syntax does not work. Having to back up and erase the last 
>closing square brace makes the logging process slower by an order of 
>At the moment I only log full objects and so there is no ambiguity. But 
>I would much prefer to have a more general approach. I see the 
>following options:
>A) Observe an implicit delimiter on sequences [...][...] or objects 
>B) Observe White space as a delimiter
>C) Observe a comma as a delimiter
>These are not disjoint sets. I think I am going to change my code to 
>accept A, B or C. However at the moment I only generate sequences 
>consistent with A.
>I think that C is the approach that fits best with JSON. For better or 
>worse, JSON uses the comma as an item separator and does not ignore 
>superfluous entries. So this requires a little more state handling than 
>absolutely necessary.
>My vote would be to require C for the log file use case for consistency 
>but as I say, I will change my code to accept A, B or C.
>>I find the idea
>>unlikely that there is some running code that 1. expects sequences of
>>JSON values with no delimiters, 2. uses a parser that precisely
>>followed the JSON specification and rejected anything but JSON objects
>>and arrays prior to this change, 3. has that parser change under it to
>>accept all kinds of values and 4. is so indifferent to the contents of
>>what it is processing that it doesn't notice that it's getting numbers
>>and strings instead of objects or arrays.
>I am not sure what 3 or 4 mean. But I have 1 and 2 already. The parser 
>returns each time that a full object is read. If there is nothing to be 
>read then it returns a null object. The encoder updates the log using 
>append only writes that can be flagged as atomic on most O/S.