Re: [Json] serializing sequences of JSON values

[Nico Williams <[e-mail]>]

On Fri, Mar 14, 2014 at 5:38 PM, Jacob Davies <[e-mail]> wrote:
> Requiring that the separator be newline and that the JSON be
> serialized without embedded newlines is convenient but seems like an
> awkward way to handle splittable sequences when there are other
> characters that are not permitted to appear in JSON texts that could
> be used with unmodified existing JSON emitters. For instance, form
> feed (ASCII 12) or record separator (ASCII 30). Yes, newline has the
> advantage of letting you use an existing read-line facility, but
> having to explain "A JSON sequence is a sequence of JSON texts - but
> they're special JSON texts with no newlines! - separated by newlines"
> seems pretty awkward.
>
> I can see how it would be convenient in some cases, but I think it's
> better for higher-level structures built on lower-level ones not to
> make special requirements of the latter. JSON has always allowed
> newlines.

If we can assume incremental JSON parsers then there's no need to say
that the separator may not appear in the JSON texts.

However, we probably shouldn't assume incremental parsers.  And,
conveniently, every encoder I've ever seen has an option for emitting
compact texts which includes not emitting newlines.

Awkward it may be, but it's handy in two ways: 1) the dumbest parsers
can handle it with no efficiency penalty, 2) sending compact texts
saves bandwidth.

jq, for example, has an incremental parser, so it can handle texts
that have embedded newlines just fine.  And it has an option to emit
compact texts.  It has no option for alternative text separators on
the encoder side, but it does accept any JSON whitespace as text
separators on the parser side and does not require a separator when
it's not required to disambiguate texts (i.e., it accepts '[][]' as a
sequence of two empty arrays).

I think allowing implementation with the dumbest parsers is a
debatable goal.  If we don't have it, instead requiring incremental
(or better) parsers, then we don't need to forbid newlines in texts,
we can say any whitespace works as a text separator, and we can say
that the separator may be omitted in some cases.

Let's debate that possible goal: do we need to permit implementation
of JSON text sequence parsing with non-incremental JSON parsers?

I don't have a strong opinion on that.  It'd certainly be most
convenient to require at least incremental JSON text parsing
capabilities, and it'd be less awkward.

Nico
--