Re: [Json] Leading and trailing whitespace

["Jim Schaad" <[e-mail]>]

My intention here has nothing to do with canonicalization and everything to
do with what constitutes a valid string from a parsing perspective.

Consider for example the case of a text file which consists of a JSON text
string with a trailing CRLF in the file.  If trailing whitespace is allowed
then the entire text file is a legal JSON text string.  If the trailing
whitespace is not allowed then it is not a legal JSON text string.  I am
just trying to clarify which is true.

This makes a difference with the argument about moving all of the values to
the top level since then the string (ignore the quotes) "   true \r\n"
cannot be matched if you just want to say it is a Boolean literal (i.e. the
non-terminator true).  Instead you need to say that it can have whitespace
on either side of it.

I will agree that the original intention probably is just a question of
academic interest.  The real question I should have asked would be are
people taking advantage of the fact.

That is the question of what about normal whitespace.

I think there is a question about parsers that would accept the string

{"a":"b"}A

As I believe there are some that will (stop when you get to the end of the
object) and some that will not.

Jim


> -----Original Message-----
> From: Paul Hoffman [mailto:[e-mail]]
> Sent: Monday, June 10, 2013 3:04 PM
> To: Jim Schaad
> Cc: [e-mail]
> Subject: Re: [Json] Leading and trailing whitespace
> 
> <no hat>
> 
> On Jun 10, 2013, at 2:54 PM, "Jim Schaad" <[e-mail]> wrote:
> 
> > The current specification allows for arbitrary whitespace to occur
> > before and after an array or object.  I would like to know if this is
> > what was intended to begin with or not.
> 
> Why is the "intention" important?
> 
> > There are two different things that could be done about this (one of
> > which would potentially be necessary if you allowed all values in a
JSON-
> text.
> 
> Why should something "be done about this"? I think you are leading into
> canonicalization, but that's not part of RFC 4627, so introducing it seems
like a
> pretty massive change.
> 
> Having said that, knowing your intention would be useful here.
> 
> --Paul Hoffman=