Re: [Json] serializing sequences of JSON values

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

Return-Path: <paulej@packetizer.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5E91A04C2 for <json@ietfa.amsl.com>; Mon, 10 Mar 2014 12:38:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.917
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFioCf1Acxa2 for <json@ietfa.amsl.com>; Mon, 10 Mar 2014 12:38:10 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id EC6691A04BC for <json@ietf.org>; Mon, 10 Mar 2014 12:38:09 -0700 (PDT)
Received: from [156.106.217.17] ([156.106.217.17]) (authenticated bits=0) by dublin.packetizer.com (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; d=packetizer.com; 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" <paulej@packetizer.com>
To: "Phillip Hallam-Baker" <hallam@gmail.com>, "Jacob Davies" <jacob@well.com>
Date: Mon, 10 Mar 2014 19:35:34 +0000
Content-Type: multipart/alternative; boundary="------=_MB5EC454FD-3192-4B94-A6B8-35A69536920E"
In-Reply-To: <CAMm+Lwg9ZCBQ8QsAE4+8rbywFUPpB9tEDzdb3C34J7cBfqu_Qw@mail.gmail.com>
Message-Id: <em2c025504-6532-4513-a339-3d71c4cdfbda@helsinki>
Mime-Version: 1.0
User-Agent: eM_Client/6.0.19861.0
Archived-At: http://mailarchive.ietf.org/arch/msg/json/7x9wqaB7n79my6wlGeFfL7z-RfQ
X-Mailman-Approved-At: Mon, 10 Mar 2014 12:38:42 -0700
Cc: Pete Resnick <presnick@qti.qualcomm.com>, Bjoern Hoehrmann <derhoermi@gmx.net>, Paul Hoffman <paul.hoffman@vpnc.org>, Larry Masinter <masinter@adobe.com>, "json@ietf.org" <json@ietf.org>, Tim Bray <tbray@textuality.com>, "Joe Hildebrand \(jhildebr\)" <jhildebr@cisco.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Nico Williams <nico@cryptonector.com>, Barry Leiba <barryleiba@computer.org>, "rfc7158@schmorp.de" <rfc7158@schmorp.de>
Subject: Re: [Json] serializing sequences of JSON values
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: "Paul E. Jones" <paulej@packetizer.com>
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=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).

Paul

------ Original Message ------
From: "Phillip Hallam-Baker" <hallam@gmail.com>
To: "Jacob Davies" <jacob@well.com>
Cc: "Nico Williams" <nico@cryptonector.com>om>; "Barry Leiba" 
<barryleiba@computer.org>rg>; "Pete Resnick" <presnick@qti.qualcomm.com>om>; 
"Bjoern Hoehrmann" <derhoermi@gmx.net>et>; "Paul Hoffman" 
<paul.hoffman@vpnc.org>rg>; "json@ietf.org" <json@ietf.org>rg>; "Paul E. 
Jones" <paulej@packetizer.com>om>; "Tim Bray" <tbray@textuality.com>om>; "Joe 
Hildebrand (jhildebr)" <jhildebr@cisco.com>om>; "Matt Miller (mamille2)" 
<mamille2@cisco.com>om>; "Larry Masinter" <masinter@adobe.com>om>; 
"rfc7158@schmorp.de" <rfc7158@schmorp.de>
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 <jacob@well.com> 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 
>separator.
>
>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 
>magnitude.
>
>
>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.
>
>--
>Website: http://hallambaker.com/