Re: [Json] Leading and trailing whitespace

[Nico Williams <[e-mail]>]

On Tue, Jun 11, 2013 at 12:14 AM, Carsten Bormann <[e-mail]> wrote:
> On Jun 11, 2013, at 05:42, Nico Williams <[e-mail]> wrote:
>> Do implementations that allow any value type at the top-level allow
>> leading and/or trailing whitespace?
>
> Yes.  E.g.,
>
>>> JSON.parse("\r\n \t 27 \r\n \t", quirks_mode: true)
> => 27
>
> (quirks_mode is the flag that switches on the non-coforming acceptance of any "value".)

Right.  I suppose I meant "by default" :)

>> *Should* they?
>
> Yes.
>
> (If you are not convinced from first principles: people have argued you can do streaming by adding whitespace, and that required being allowed to add whitespace :-)

Indeed, I've argued as much.  The whitespace is only needed to
distinguish end-of-message from a pemature EOF that might not
otherwise be understood as such.

> So we will have to add a production:
>
>         JSON-value = ws value ws
>
> That didn't seem too hard.

Do we need to remove whitespace elsewhere in the ABNF?  Or is
redundancy there OK?

> Thanks for pointing this out, Jim.

Yes, thanks!

> This production can be in 4627-bis or in the document that defines the application/json-value media type, if we want to go the latter route.

Sure.  For now I'm still arguing for allowing any value type at the top-level.

> Grüße, Carsten
>
> PS.: Just to show that trailing whitespace is indeed properly parsed:
>>> JSON.parse("\r\n \t 27 \r\n \t 28", quirks_mode: true)
> JSON::ParserError: 795: unexpected token at '28'

Ah, good job.

Nico
--