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

[Tim Bray <[e-mail]>]

I agree with every point Paul made.  I’m completely convinced that we need
an unambiguous can’t-appear-in-JSON separator/prefix.    Anything smaller
than 1F other than the characters included in JSON would be fine by me.
 How about U+0000?


On Thu, Jun 5, 2014 at 10:01 AM, Paul Hoffman <[e-mail]> wrote:

> <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
> _______________________________________________
> json mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/json
>



-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)