Re: [Json] serializing sequences of JSON values

[Nico Williams <[e-mail]>]

On Mon, Mar 10, 2014 at 1: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. I find the idea
> unlikely that there is some running code that 1. expects sequences of

This exists:

http://stedolan.github.io/jq

and existed prior to the new RFC, and it happily consumed (parsed),
processed, and produced (encoded) sequences of top-level values of any
JSON value type.

Code exists that uses jq in that way.  jq happens to always emit a
newline after emitting a JSON text.

> 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

Every JSON parser I've ever used or read the docs for (probably half a
dozen) has an option to parse things other than arrays/objects at the
top-level.

If the sequenced texts are separated by newlines (or, really, any
whitespace) and the parser can be fed a chunk of octets at a time
until a complete text is read, then it's trivial to build an
application that consumes sequences of texts.  There are other parser
features that can be used to build such an application, but since
numbers must be delimited somehow ("on the right"), the simple rule to
follow is to just emit a newline after any JSON text.

> 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.

Your imagination fails you:

jq 'if type == "number" then ... elif type == "string" then ... elif
type == "array" then ... else ... end'

You can do the same in Python, JavaScript, Ruby, C, and so on and on.

You might argue that this is silly, but I'd say once more that your
imagination fails you.  Suppose I'm grepping for specific values and I
want to output the paths to them in a stream of texts whose form I
know little about -- being new to some project with lousy docs I might
be trying to understand some data.  Why not?

For me the main issue here is that there's an ambiguity (see separate
thread) that is best resolved by always emitting a newline after each
text in a sequence.

Nico
--