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

Jacob Davies <> Mon, 28 April 2014 21:04 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EC5921A7035 for <>; Mon, 28 Apr 2014 14:04:23 -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 E73w7xm3MtEi for <>; Mon, 28 Apr 2014 14:04:22 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c01::235]) by (Postfix) with ESMTP id ABAC71A86DE for <>; Mon, 28 Apr 2014 14:04:18 -0700 (PDT)
Received: by with SMTP id jt11so4521380pbb.26 for <>; Mon, 28 Apr 2014 14:04:18 -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:content-transfer-encoding; bh=pAh3fTc/Ll5xQCxezE197UheyOKXL8LN851KtNOLzKc=; b=abcGyQpckyifXln3XjR2SEC4DUTS1BKPFqoeB4Ia9LsOnCIZspbPnIi5251WeJtbRO BPy6BCNi9eGh27CHVibicp/msbyt8vrVcKldIXdtY5eu83W1QbRvMizchNn2K+lc2puS k6o0lTz9BuFyd/AnlUaXe4wQbHI20XzRt2XNEZstJ99R9AuMfm5AD/eoh52mDkfBjdSD DPcgdOuOz+VUf+xR7la9aVbeCgpIBrVVX66+WpdFneYdf0FgRXnVOQ/3gKbxix+sTs8h Llz3Uh+2LGj9tRhvySknOlJumYULUnBkIyvgR43arBZOsSZL93h/CYBgZQhH8I6aXIfr p6wg==
X-Received: by with SMTP id yp4mr27794800pac.94.1398719057934; Mon, 28 Apr 2014 14:04:17 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 28 Apr 2014 14:03:57 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Jacob Davies <>
Date: Mon, 28 Apr 2014 14:03:57 -0700
X-Google-Sender-Auth: V3XH0rylxmUWGmXVIssiMZvGwFM
Message-ID: <>
To: Nico Williams <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Matt Miller <>, Tim Bray <>, IETF JSON WG <>
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: Mon, 28 Apr 2014 21:04:24 -0000

Requiring an object at the top level breaks the symmetry of JSON,
rules out many useful applications (or requires a clumsy envelope for
them), and needlessly conflicts with actual practice. It is solving a
problem I am not convinced anyone really runs into - using (say) a
JSON string instead of a JSON object and then oops not being able to
pass along some extra metadata later (and for some reason HTTP headers
or some similar mechanism won't work). In fact one of the nice things
about JSON is that if you change your mind and decide to send objects
instead of strings in some application you can know that the transport
will support them; you can even allow older senders to keep sending
strings, and new ones to send objects, and have the receiver accept
both. Requiring further future-proofing with top-level objects seems
very invasive.

On Mon, Apr 28, 2014 at 1:36 PM, Nico Williams <> wrote:
> On Mon, Apr 28, 2014 at 3:20 PM, Tim Bray <> wrote:
>> Protocols with messages which are objects are better than other protocols,
>> because they are architecturally friendly to MustIgnore policies.
>> Allowing top-level JSON to be a primitive - true, null, 42 - is batshit
>> crazy for anything the IETF might contemplate, and one of I-JSON’s main
>> virtues is ruling that out.
> What if the service outputs JSON texts output by a jq program supplied
> by the client and applied to server-side data?
>> I don’t think top-level arrays are actively harmful at the same level, but
>> the MustIgnore is a pretty big value-add, forcing people to sort-of
>> future-proof themselves even when they haven’t realized why that’s a good
>> idea.
> Why can't schema changes be communicated out-of-band?  Apps request
> JSON in a particular schema; servers report the schema when the schema
> was not requested...
> I can see the value in recommending the use of top-level objects in
> general, just not in requiring it.
> Still, I think if you want to say "so don't use I-JSON", I think
> that's mostly fine.  The only problem that comes up is the possibility
> that I-JSON would crowd out JSON to the point where non-I-JSON might
> not be usable.  I think what I'd want to see there is that JSON
> parsers should really just have an option as to this, rather than have
> I-JSON parsers that are not also JSON parsers.
> Nico
> --
> _______________________________________________
> json mailing list