Re: [Json] Working Group Last Call on draft-ietf-json-text-sequence

[Nico Williams <[e-mail]>]

On Thu, May 22, 2014 at 8:32 PM, John Cowan <[e-mail]> wrote:
> Tim Bray scripsit:
>> The second sentence is klunky and I don’t understand what it’s trying
>> to say.  I suggest attaching the first sentence to the previous para
>> and just losing the 2nd sentence.
>
> The key to understanding the second sentence is that "online" means what
> you and I call "streaming".

I classify JSON parsers as follows:

 - streaming -> consume input text incrementally AND produce results
incrementally (e.g., a path+value pair for each scalar value in a
text)

 - online -> consume input text incrementally (but -perhaps- produces
one value for a complete parsed text)

 - not-online -> consumes input text non-incrementally, must be
provided complete texts

Streaming parsers are also online parsers in my classification.

Perhaps I'm using the wrong terminology, but I've yet to see a
standard classification of JSON parsers that captures these
distinctions.

The value of JSON text sequences comes from not having to use a
streaming parser (since they can be unwieldy).  There is also value on
the encoding side: not having to use a streaming encoder, nor manually
emit an opening '[' and ','s between texts.

A real-world example of this is jq (https://stedolan.github.io/jq),
which has an online-but-streaming parser, and which naturally supports
JSON text sequences.  jq can consume (and produce) JSON text sequences
in a "streaming" manner even though its JSON parser and encoder are
not streaming.

Nico
--