Re: [Json] I-JSON Tpic #2: Top-Level

Jacob Davies <> Wed, 21 May 2014 06:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DB88C1A0817 for <>; Tue, 20 May 2014 23:03:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WV4YKxSfrpKm for <>; Tue, 20 May 2014 23:03:06 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9DABF1A078B for <>; Tue, 20 May 2014 23:03:06 -0700 (PDT)
Received: by with SMTP id bs8so7052522wib.12 for <>; Tue, 20 May 2014 23:03:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=C+/0rd+l1fxnlXkd7TBMVuKcPUMB66BdrT+AFgaAlOo=; b=YJpi5MnCiYZLl0VTes5rTfEjVrFd1X9VD18sjTMisNXa6hNW8z0/MaIku4nk/9s3hD 9TyMjOyIYKuSexsUagZi4H0gYAmp70eAg7tx7yvhVf7KGVWZZhbQjwY6ECSL1l7pOjPs Hb3aqsk7HPn0Kzl3itJ0bS4Owr8vBsV5KxwGAboKMMDX4HSW5ElaYc0KFrQYLhNEHF1Q JSFtpGt0aA5uCl9Gj4/O6JwV7Tf/5d/xx9n6+0y/kMBixX/8FVzSEiz2pOAJ/o2xejnv LAqPZkW6WSJzkpyIGWv8/gobJpapmQOMVJS31agfK7ylwzzNgPF4hBjm0nqyxbNfdIit PMpQ==
X-Received: by with SMTP id cl7mr8321934wib.26.1400652184877; Tue, 20 May 2014 23:03:04 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 20 May 2014 23:02:44 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: Jacob Davies <>
Date: Tue, 20 May 2014 23:02:44 -0700
X-Google-Sender-Auth: Q25GD1NEHl66BgIhMmpT_eblxso
Message-ID: <>
To: Paul Hoffman <>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [Json] I-JSON Tpic #2: Top-Level
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, 21 May 2014 06:03:08 -0000

On Tue, May 20, 2014 at 1:50 PM, Paul Hoffman <> wrote:
> The goal of this document is to maximize interoperability. RFC 4627 and other specs had the rule that JSON texts had to be objects or arrays. Restricting JSON texts *in this profile* maximizes interoperability better than RFC 7159 did.

Restricting top-level elements to objects or objects and arrays
repeats the mistake of the original JSON specification. But almost
every JSON parser ignored that advice, most importantly including the
Javascript JSON.parse() method.

Unlike the other concerns being addressed, the issue of non-object
top-level elements is not a subtle gotcha. If an application says it
emits or receives JSON but fails to specify the numeric range they
support or fails to specify the behavior when duplicate keys are given
or fails to specify that non-character code points are disallowed,
there is a real risk of subtle interoperability problems. But if an
application says it emits or receives JSON strings as JSON documents,
the interoperability error with some client that does not support
top-level strings is gross. There is no chance of a subtle failure.

Mostly I think including this constraint is a mistake because it
overshadows the excellent advice given in the rest of the I-JSON spec
on the limits of numeric precision, non-character code points, and
duplicate keys. It makes I-JSON an unsuitable drop-in replacement for
JSON by making certain unambiguous and nearly-universally-supported
use cases illegal. This is throwing the baby out with the bathwater;
the rationale that it presents a real interoperability concern is not
really supportable, as the general indifference to dropping this
constraint in recent JSON specifications makes obvious.