Return-Path: 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 5411121F9E9D for ; Tue, 8 Oct 2013 12:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 53I812eNVVOK for ; Tue, 8 Oct 2013 12:22:00 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9541621F9E89 for ; Tue, 8 Oct 2013 12:21:59 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id w7so7388312lbi.29 for ; Tue, 08 Oct 2013 12:21:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=irm+KH9iXGOEwFJDBmr34E6rOpmZeYa8KokZC0xOB1w=; b=nBtnP200MlxSz91rKGbU3xuFOQGFMlUa9i7RyOT6e07VIKz8BsTLW0PA/l0qitVX8t 5VtXxZ1omKYw7bXJax/ozFNwpjazCyeaMP+/357kAEX/fMVlhk43IMtWXfSM0kwekG01 Zqf2uJgi4+Vc0UIi/XIAUjoKBrFSzCX3xwDX+7E+0KI/2qWj1xIdlZbSY5+eBu5VgcCt ngZx3MclUKFcu6bdDiDVXbOYj3ZSyUkkYxQJvTRBy33BU8qh9atSElIrNwKWaUkiV8Oq Sw1Z8cn1tW8TFrwgo6hPiOyxDDFH0FocmkEsHLbY1Dqw3SRCuCSVl7awunv/OsPjn960 +IWw== MIME-Version: 1.0 X-Received: by 10.112.57.49 with SMTP id f17mr3800089lbq.26.1381260118507; Tue, 08 Oct 2013 12:21:58 -0700 (PDT) Received: by 10.112.173.133 with HTTP; Tue, 8 Oct 2013 12:21:58 -0700 (PDT) In-Reply-To: <525455D4.8090105@gmail.com> References: <525429ED.5000705@gmail.com> <04FC3123-33A4-40DA-AD5D-DA543435DE56@wirfs-brock.com> <20131008164219.GA16081@mercury.ccil.org> <52544E3C.7000907@gmail.com> <525455D4.8090105@gmail.com> Date: Tue, 8 Oct 2013 12:21:58 -0700 Message-ID: From: Brian Kardell To: "Peter F. Patel-Schneider" Content-Type: multipart/alternative; boundary=001a1133eacab4c83604e83faecb X-Mailman-Approved-At: Tue, 08 Oct 2013 12:36:43 -0700 Cc: Allen Wirfs-Brock , John Cowan , JSON WG , Tim Bray , Larry Masinter , "www-tag@w3.org" Subject: Re: [Json] FYI ECMA, W3C, IETF coordination on JSON X-BeenThere: json@ietf.org 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, 08 Oct 2013 19:25:11 -0000 --001a1133eacab4c83604e83faecb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Oct 8, 2013 at 11:58 AM, Peter F. Patel-Schneider < pfpschneider@gmail.com> wrote: > Yes indeed. Yes indeed. The double quote may not appear within > quotation marks, by a two-to-one vote. > > peter > > > On 10/08/2013 11:32 AM, Tim Bray wrote: > >> On the other hand, the opening paragraph of section 9 makes sure that >> you=92re really clear about which characters may and may not be placed >> between quotation marks. >> >> >> On Tue, Oct 8, 2013 at 11:26 AM, Peter F. Patel-Schneider < >> pfpschneider@gmail.com > wrote: >> >> The paragraph on numbers, see below, seems rather dangerous, as well >> as >> being incorrect. The paragraph on strings, also below, ignores all >> the >> problems with escaped code units that do not represent a Unicode cod= e >> point. >> >> peter >> >> >> On 10/08/2013 09:42 AM, John Cowan wrote: >> >> Allen Wirfs-Brock scripsit: >> >> The draft was approved by a letter ballot of the Ecma Genera= l >> Assembly. It is now available as Ecma-404: >> >> Almost all of it is derived directly from the RFC, with some >> editorial >> cleanup. The Introduction, however, is new. I reproduce it her= e >> in >> case >> the Editor wishes to mine it for anything: >> [...] >> >> >> JSON is agnostic about numbers. In any programming language= , >> there can be a variety of number types of various capacitie= s >> and complements, fixed or floating, binary or decimal. That >> can make interchange between different programming language= s >> difficult. JSON instead offers only the representation of >> numbers >> that humans use: a sequence of digits. All programming >> languages >> know how to make sense of digit sequences even if they >> disagree >> on internal representations. That is enough to allow >> interchange. >> >> JSON text is a sequence of Unicode code points. JSON also >> depends >> on Unicode in the hex numbers used in the \u escapement [si= c] >> notation. >> [...] >> >> >> >> > > So I guess my big question I keep asking myself is this: Despite the fact that it didn't involve standards bodies and committees to get out the door - JSON is really *really* interoperable. There are potentially some edge cases, but given its importance to the Web it does seem like the ECMA version is the most important baseline here. If we want to make improvements, why not just invent some other thing - not JSON... Call it "super json" or "phil" or - just something else...And let that something else attempt to address perceived problems and make some minor comments about the ability to parse a subset of it with the standard JSON parsers that conform to ECMA-404 or something and then go out there and compete and see if it actually does better. Maybe it will and we can all go have beers and laugh about it, but - maybe it won't and at least we don't have to break things. --=20 Brian Kardell :: @briankardell --001a1133eacab4c83604e83faecb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Tue, Oct 8, 2013 at 11:58 AM, Peter F. Patel-Schneider <pf= pschneider@gmail.com> wrote:
Yes indeed. =A0Yes indeed. =A0 The double qu= ote may not appear within quotation marks, by a two-to-one vote.

peter


On 10/08/2013 11:32 AM, Tim Bray wrote:
On the other hand, the opening paragraph of section 9 makes sure that you= =92re really clear about which characters may and may not be placed between= quotation marks.


On Tue, Oct 8, 2013 at 11:26 AM, Peter F. Patel-Schneider <pfpschneider@gmail.com &= lt;mailto:pfpsc= hneider@gmail.com>> wrote:

=A0 =A0 The paragraph on numbers, see below, seems rather dangerous, as wel= l as
=A0 =A0 being incorrect. =A0The paragraph on strings, also below, ignores a= ll the
=A0 =A0 problems with escaped code units that do not represent a Unicode co= de point.

=A0 =A0 peter


=A0 =A0 On 10/08/2013 09:42 AM, John Cowan wrote:

=A0 =A0 =A0 =A0 Allen Wirfs-Brock scripsit:

=A0 =A0 =A0 =A0 =A0 =A0 The draft was approved by a letter ballot of the Ec= ma General
=A0 =A0 =A0 =A0 =A0 =A0 Assembly. =A0It is now available as Ecma-404:

=A0 =A0 =A0 =A0 Almost all of it is derived directly from the RFC, with som= e editorial
=A0 =A0 =A0 =A0 cleanup. =A0The Introduction, however, is new. =A0I reprodu= ce it here in
=A0 =A0 =A0 =A0 case
=A0 =A0 =A0 =A0 the Editor wishes to mine it for anything:
=A0 =A0 =A0 =A0 [...]


=A0 =A0 =A0 =A0 =A0 =A0 =A0JSON is agnostic about numbers. In any programmi= ng language,
=A0 =A0 =A0 =A0 =A0 =A0 =A0there can be a variety of number types of variou= s capacities
=A0 =A0 =A0 =A0 =A0 =A0 =A0and complements, fixed or floating, binary or de= cimal. That
=A0 =A0 =A0 =A0 =A0 =A0 =A0can make interchange between different programmi= ng languages
=A0 =A0 =A0 =A0 =A0 =A0 =A0difficult. JSON instead offers only the represen= tation of numbers
=A0 =A0 =A0 =A0 =A0 =A0 =A0that humans use: a sequence of digits. All progr= amming languages
=A0 =A0 =A0 =A0 =A0 =A0 =A0know how to make sense of digit sequences even i= f they disagree
=A0 =A0 =A0 =A0 =A0 =A0 =A0on internal representations. That is enough to a= llow interchange.

=A0 =A0 =A0 =A0 =A0 =A0 =A0JSON text is a sequence of Unicode code points. = JSON also depends
=A0 =A0 =A0 =A0 =A0 =A0 =A0on Unicode in the hex numbers used in the \u esc= apement [sic]
=A0 =A0 =A0 =A0 =A0 =A0 =A0notation.
=A0 =A0 =A0 =A0 [...]






So I guess my big question I keep asking myself is t= his: =A0Despite the fact that it didn't involve standards bodies and co= mmittees to get out the door - JSON is really *really* interoperable. =A0Th= ere are potentially some edge cases, but given its importance to the Web it= does seem like the ECMA version is the most important baseline here. =A0If= we want to make improvements, why not just invent some other thing - not J= SON... Call it "super json" or "phil" or - just somethi= ng else...And let that something else attempt to address perceived problems= and make some minor comments about the ability to parse a subset of it wit= h the standard JSON parsers that conform to ECMA-404 or something and then = go out there and compete and see if it actually does better. =A0Maybe it wi= ll and we can all go have beers and laugh about it, but - maybe it won'= t and at least we don't have to break things.
=A0
--
Brian Kardell :: @briankardell=A0
--001a1133eacab4c83604e83faecb--