No, it doesn't. In JSON Sequence, you are guaranteed that every JSON value has a specific start (U+001E) and end (LF) character, and it is guaranteed that the start character can't appear in the JSON representation, because control characters in JSON strings have to be \U-encoded.

In JSON Lines, it is guaranteed that the end character doesn't appear within the JSON representation either, so no start character is needed.

Both are robust against incomplete JSON representations.  They are also robust against accidentally adjacent values (just writing 3 and then 4 will be reread as 34 otherwise).  Unfortunately a single doc can't conform to both because a Json Lines processor will break on reading the U+001E.

On Tue, Jan 21, 2020 at 5:49 AM Amirouche Boubekki <xxxxxx@gmail.com> wrote:
Le dim. 19 janv. 2020 à 04:20, John Cowan <xxxxxx@ccil.org> a écrit :
>
> Correct.
>
> On Sat, Jan 18, 2020 at 10:20 PM Amirouche Boubekki <xxxxxx@gmail.com> wrote:
>>
>> Le sam. 18 janv. 2020 à 22:58, John Cowan <xxxxxx@ccil.org> a écrit :
>> >
>> > I suggest that the stream reader conform to RFC 7454.  This is a protocol for having multiple JSON values in the same stream by making sure that no two values can run together.  For example, outputting 12 followed by 24 would be reread as 1224.  Furthermore, 7454 allows recovering from a broken JSON object and synchronizing correctly on the next object.
>> >
>> > For the stream reader, this basically means that it is legal to have a single U+001E in the input just before parsing a top-level value.
>> >
>> > The json-stream-writer procedure would have an additional argument, which if true would cause it to write U+001E before every top-level value and U+000A after every top-level value.
>>
>> Are you referring to https://tools.ietf.org/html/rfc7454?
>>

Does the RFC contradict JSON lines pseudo-standard: http://jsonlines.org/