Re: [Json] JSON: remove gap between Ecma-404 and IETF draft

Allen Wirfs-Brock <allen@wirfs-brock.com> Wed, 13 November 2013 21:40 UTC

Return-Path: <allen@wirfs-brock.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C9321E8154; Wed, 13 Nov 2013 13:40:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.932
X-Spam-Level:
X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uG0Q1oLbQ36P; Wed, 13 Nov 2013 13:40:41 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id ACDE521E8165; Wed, 13 Nov 2013 13:39:26 -0800 (PST)
Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.22]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <allen@wirfs-brock.com>) id 1Vgi9k-000MOc-H0; Wed, 13 Nov 2013 21:39:24 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 69.64.236.244
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX18SUWjx8PakZ0HF06+qqSh7q+KKPX8bxDI=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="us-ascii"
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <3389CD77-B1CC-4A76-907A-6D400DA028CC@vpnc.org>
Date: Wed, 13 Nov 2013 13:39:16 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <967BEA5F-FA98-4A9E-8311-8295528F30E7@wirfs-brock.com>
References: <CEA92854.2CC53%jhildebr@cisco.com> <3389CD77-B1CC-4A76-907A-6D400DA028CC@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.1085)
Cc: IETF Discussion <ietf@ietf.org>, JSON WG <json@ietf.org>, Joe Hildebrand Hildebrand <jhildebr@cisco.com>, Anne van Kesteren <annevk@annevk.nl>, "www-tag@w3.org" <www-tag@w3.org>, es-discuss <es-discuss@mozilla.org>
Subject: Re: [Json] JSON: remove gap between Ecma-404 and IETF draft
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Nov 2013 21:40:47 -0000

On Nov 13, 2013, at 1:27 PM, Paul Hoffman wrote:

> <no hat>
> 
> On Nov 13, 2013, at 12:24 PM, Joe Hildebrand (jhildebr) <jhildebr@cisco.com> wrote:
> 
>> We would also need to change section 8.1 according to the mechanism that
>> was previously proposed:
>> 
>> 00 00 00 xx  UTF-32BE
>>   00 xx ?? xx  UTF-16BE
>>   xx 00 00 00  UTF-32LE
>>   xx 00 xx ?? UTF-16LE
>>   xx xx ?? ?? UTF-8
>> 
>> in order to account for strings at the top level whose first character has
>> a codepoint greater than 127.
> 
> A string at the top level of a JSON text still needs to start with an ASCII " character, so the logic is still fine, I believe.
> 
> Carsten's point about whitespace is more problematic. Does the ECMA-404 definition of a JSON text allow it to start with one (or more) whitespace characters? The text in that document says:
> . . .
> A JSON text is a sequence of tokens formed from Unicode code points that conforms to the JSON value grammar. The set of tokens includes six structural tokens, strings, numbers, and three literal name tokens.
> . . .
> Insignificant whitespace is allowed before or after any token.
> . . .
> 
> It would be nice if ECMA-404 was clearer on this, given that the racetrack illustrations show everything other than the whitespace. In specific, it would be good to know whether or not the racetrack for "value" in Section 5 is meant to have optional whitespace at the left and right to match the above text. If TC39 could say for certain on that, it would be useful to the community.

Yes, leading white space is allowed:

"The set of tokens includes the six structural tokens, *strings*,  *numbers*, ..."  (emphasis added)

"Insignificant whitespace is allowed before or after any token"

The elements matched by the value production are all tokens (or productions that begin and end with a token) so whitespace can occur to the left or right of any value

Allen