Re: [Json] Leading and trailing whitespace

Paul Hoffman <> Tue, 11 June 2013 02:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C2AA821F8808 for <>; Mon, 10 Jun 2013 19:53:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.44
X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9XAHZCtaxmWf for <>; Mon, 10 Jun 2013 19:53:51 -0700 (PDT)
Received: from (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by (Postfix) with ESMTP id 0758021F86C0 for <>; Mon, 10 Jun 2013 19:53:49 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.5/8.14.5) with ESMTP id r5B2rPxO062696 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Jun 2013 19:53:26 -0700 (MST) (envelope-from
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Paul Hoffman <>
In-Reply-To: <070b01ce664b$e5e0ac10$b1a20430$>
Date: Mon, 10 Jun 2013 19:53:25 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <06c101ce6625$0f891bf0$2e9b53d0$> <> <06e901ce6638$e8f27a90$bad76fb0$> <> <070b01ce664b$e5e0ac10$b1a20430$>
To: "Jim Schaad" <>
X-Mailer: Apple Mail (2.1508)
Subject: Re: [Json] Leading and trailing whitespace
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Jun 2013 02:54:09 -0000

On Jun 10, 2013, at 7:32 PM, "Jim Schaad" <> wrote:

> Ok - I used the wrong term - I need to get them clearer, I still am trying
> to learn - Please read JSON text for JSON text string.  I was not using
> string as a value in this location.

You can't ask that question because the current doc only allows arrays and objects at the top level, and the starting character for each of those allow for white space.

You might be asking "if we allow other JSON items at the top level, will we also allow optional whitespace before and after". But that's a supposition, not a question about what is in the document now.

>>> 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.
>> The current grammar does not allow whitespace around "true" for that
>> boolean value.
> Actually it does, but the whitespace comes from the container it is in.  

You have changed the subject of the question, then. You were asking about the top level, without a container. I claim my answer is correct for the question you asked.

> The
> current grammar does not allow true at the top level and if that does not
> change then the above remains a moot point.  Note that the text was talking
> about moving all values to the top level.

None of the objects other than arrays and objects have optional whitespace. None.

> Yes -but what I am saying is that there are (probably) parsers which stop
> before the string has been fully consumed.  Thus they would accept the
> string as valid.

There are (probably) parsers that do all sorts of stupid, non-conformant things. Why is that relevant here?

--Paul Hoffman