Re: [Json] serializing sequences of JSON values

["Paul E. Jones" <[e-mail]>]

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" <[e-mail]>
To: "Jacob Davies" <[e-mail]>
Cc: "Nico Williams" <[e-mail]>om>; "Barry Leiba" 
<[e-mail]>rg>; "Pete Resnick" <[e-mail]>om>; 
"Bjoern Hoehrmann" <[e-mail]>et>; "Paul Hoffman" 
<[e-mail]>rg>; "[e-mail]" <[e-mail]>rg>; "Paul E. 
Jones" <[e-mail]>om>; "Tim Bray" <[e-mail]>om>; "Joe 
Hildebrand (jhildebr)" <[e-mail]>om>; "Matt Miller (mamille2)" 
<[e-mail]>om>; "Larry Masinter" <[e-mail]>om>; 
"[e-mail]" <[e-mail]>
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 <[e-mail]> 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/