Re: [Json] Proposed Wording for New WG Charter

[Nico Williams <[e-mail]>]

On Tue, Mar 18, 2014 at 01:01:28PM +0900, "Martin J. Dürst" wrote:
> >The WG will work on a format for a streamable sequence of JSON texts.
> >The work will start from draft-williams-json-text-sequence-00.
> 
> There have been various discussions about such an idea, and various
> details of it, on the WG list. However, as far as I'm aware, the
> question of whether this should be part of the WG's work wasn't
> brought up, and has not been discussed. I'm therefore quite
> surprised to see this here, and request that it be retracted and if
> necessary discussed separately before being included in a charter
> proposal.

I'm somewhat surprised as well.  I do think the call by the chairs that
there was consensus for it is plausible, but it's true that it was never
stated that it was being considered as a work item, and that might
actually change the consensus.

> As to substance, I strongly oppose the addition of this work item to
> the WG charter. In my understanding, the need for such a format is
> marginal at best (*), and putting it on the WG charter would tie up
> significant resources that can be better used elsewhere.
> Standardizing such a format would also cause needless confusion in
> the JSON ecosystem. (#)
> 
> (*) In particular in open exchange on the Internet.

That may be.  I don't have apps to point to that use this now over -say-
HTTP.  I do have apps that use JSON sequences internally and as file
formats.  I would like to be able to use JSON sequences over HTTP, but
wishing ain't getting and for all I know it may never happen.  OTOH, I
think a number of people have agreed that JSON sequences have useful
properties, so there appears to be enough interest.

> (#) I can already hear questions and discussions such as "Should we
> use an array or a sequence here?" and "What about sequences inside
> arrays?" and so on.

Re (#): Sequences are of JSON texts, and JSON texts are well-defined
enough that it's clear that sequences cannot appear in JSON texts.  Full
stop.

The idea is twofold: to obtain a happy middle between streaming and
non-streaming parsing of sequences (arrays if you prefer) of values, and
to not require a closing array/sequence token (']') because it may never
arrive (e.g., in the case of a logfile).

In particular, the ability to construct a streaming JSON sequence
parsers out of off-the-shelf non-streaming (but incremental[*]) JSON
text parsers is quite convenient given that a) all-streaming-all-the-
time text parsing is inconvenient, b) non-streaming parsers abound.

Nico

[*] Non-streaming parsers that require a fully-formed text be provided
    as input (e.g., json.loads()), cannot be efficiently used to parse
    sequences without the encoder having made it easier for the sequence
    parser to identify the ends of the texts.