Re: [Json] serializing sequences of JSON values

[Phillip Hallam-Baker <[e-mail]>]

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/