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

["Manger, James" <[e-mail]>]

>> 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.
* An RS causes Chrome to treat a file as binary data, instead of text.
* 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.
* No one uses RS.
* RS is now labelled INFORMATION SEPARATOR TWO, not RECORD SEPARATOR.
* We aren't using INFORMATION SEPARATOR ONE, THREE or FOUR.
* A newline as a JSON value terminator is sufficient to parse a JSON sequence unambiguously.
* RS doesn't work well with APIs that read text by the line.
* 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).
* 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.
* The awkwardness of RS will mean many implementations will be lenient, but leniency becomes "expected" which leads to interop problems.

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

--
James Manger