Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on draft-ietf-json-text-sequence)

[Paul Hoffman <[e-mail]>]

<no hat>

As a summary from below: you prefer a more normal character like NL plus the need to escape it in strings, versus an obscure character like RS that requires no escaping. Is that correct?

On Jun 4, 2014, at 11:25 PM, Manger, James <[e-mail]> wrote:

>>> JSON-sequence = *( ws %1e JSON-text )
> 
> RS as a JSON sequence prefix or separator was a bad idea when discussed a month ago and still is.
> 
> * You cannot (easily) enter an RS in notepad.
> * You cannot (easily) enter an RS in vi.
> * You cannot see an RS.

It seems like the purpose of draft-ietf-json-text-sequence is to create a format that can be used for log files and other such files that are constantly added to. If so, then the above complaints are not really relevant, right?

> * An RS causes Chrome to treat a file as binary data, instead of text.

Ditto.

> * Cut-n-paste a JSON value with an invisible RS prefix and the result is NOT JSON, ie it will fail with a JSON parser as RS is not allowed in JSON.

That will be true of anything other than a character that doesn't need to be escaped, right? People asked for RS (or something like it) so that they didn't have to deal with escaping when the value chosen was also in a string. 

> * No one uses RS.
> * RS is now labelled INFORMATION SEPARATOR TWO, not RECORD SEPARATOR.
> * We aren't using INFORMATION SEPARATOR ONE, THREE or FOUR.

All irrelevant. We are creating a new specification.

> * A newline as a JSON value terminator is sufficient to parse a JSON sequence unambiguously.

Sure. And it also causes the need to have escaping.

> * RS doesn't work well with APIs that read text by the line.

Are there JSON APIs that do that?

> * Detecting a newline that separates JSON values is more complex than detecting an RS character, but it is not that complex (eg handful of lines of code).

The people who asked for RS seemed more concerned about escaping newlines in the JSON being written, not detecting it on the incoming. Do you agree that that is also a concern?

> * An RS prefix detects only slightly more cases of accidentally truncated writes (in the middle of a top-level number, in a top-level string in the middle of an escape sequence) -- not enough to be compelling.

That was not the major motivation, however.

> * The awkwardness of RS will mean many implementations will be lenient, but leniency becomes "expected" which leads to interop problems.

That is a prediction of the future.

> "A JSON sequence is the concatenation of zero or more JSON values, where each JSON value is terminated with a newline."
> 
> Simple to understand. Simple to write. Simple enough to parse. Simple enough to resync from the middle of a sequence. Almost identical recovery from accidental corruption is possible in almost all the same instances regardless of whether an RS prefix or newline suffix is used.

Sure, but it ignores the issue many people had about escaping.

--Paul Hoffman