Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values)

Phillip Hallam-Baker <> Wed, 12 March 2014 11:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EA4F11A0960 for <>; Wed, 12 Mar 2014 04:35:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7Qi3LtPXATWb for <>; Wed, 12 Mar 2014 04:35:12 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c04::22c]) by (Postfix) with ESMTP id E8B261A0968 for <>; Wed, 12 Mar 2014 04:35:11 -0700 (PDT)
Received: by with SMTP id c11so6567542lbj.31 for <>; Wed, 12 Mar 2014 04:35:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Qle/FSQYuiEimO1GI1IkXM+WmYoyAEjsrOJTGJwMEyk=; b=DaQa0IrKy8qJ1Qs1Bbnlh22ED8QfPsL6z3pgMvmHRLmIAQ4TjuklChl72FUOkQX/LY dTtu8MFi3TU6peI/wcau55Srt7rFXMqKFeFefYytMwauNRBQ86Sp5CKs4GPby4VOeSaY U/ujR/8M4Sl0UWb1UEW7ZgFSYzkodXiWXhtXoaaE9ilLeHZe/f4eLuhHzrrXsgoHEzkR U+h3VIdpavmzyOxwaWlctoZf5J/BjJpOo22SS8zP2NQiIfuaaWYqsXHGFBN4OID+bxdZ Gi/zuo9Ki4+ja/gYHmSOh6jFHsT3qrUQMEpknAp2r69kDQj+JJ1gjSHCcUW+xtYyg85o f9EQ==
MIME-Version: 1.0
X-Received: by with SMTP id ej3mr31561723lad.17.1394624105263; Wed, 12 Mar 2014 04:35:05 -0700 (PDT)
Received: by with HTTP; Wed, 12 Mar 2014 04:35:05 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Date: Wed, 12 Mar 2014 07:35:05 -0400
Message-ID: <>
From: Phillip Hallam-Baker <>
To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= <>
Content-Type: multipart/alternative; boundary=001a1134635a63b79504f4673af3
Cc: Nico Williams <>, Tim Bray <>, "" <>
Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values)
X-Mailman-Version: 2.1.15
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: Wed, 12 Mar 2014 11:35:14 -0000

On Wed, Mar 12, 2014 at 5:44 AM, "Martin J. Dürst"

> On 2014/03/12 04:19, Phillip Hallam-Baker wrote:
>> On Tue, Mar 11, 2014 at 2:08 PM, Nico Williams <
>> >wrote:
>  JSON text sequences would be a new Proposed Standard (if we go there)
>>> but like JSON, there exist uses of this "new" thing already -- that
>>> is, before we get to writing the RFC.
>  I think finding a standard JSON way to meet this requirement is
>> appropriate. Blessing a particular approach that isn't in the existing
>> grammar is not AFIK.
> For the record, I strongly agree.
> Seeing claims that we need a separate spec just because an initial '[',
> interleaving ','s, and a potential(1) final ']' is too much to deal with
> really surprises me.

The final ']' completely kills the use of append only logs. Which means
that you can't rely on the O/S append operation to give atomicity.

So there is a performance and a security issue here.

> At the utmost, this might become an Informational RFC if some people
> really, really want it, but it should NOT become a working item of this
> group, nor should it go to standards track.
> Why? JSON is great, but the more variation we get, the more we end up with
> a *big mess*, even if every step may be small and look good.

I don't think that is what happened to XML or CORBA.

The CORBA people had no idea of how to communicate what they were
attempting to do. Plus they were trying to exchange C++ objects that
weren't C++ objects at a time when C++ was not functional or stable.

XML is the way it is because it is trying to be a document markup not a
data markup.

> As far as I have heard (no first hand experience, fortunately), CORBA
> ended up that way. Many people, in particular in the JSON community, see
> XML that way. Similar things have been said about ASN-1, although that may
> have been complicated from the start (again, fortunately no first hand
> experience).

If we stick to commas then the production already exists in the spec:

json-text = ws-value

json-texts = ws-value (',' ws-value)