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

"Manger, James" <> Wed, 30 April 2014 05:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5E9D31A2130 for <>; Tue, 29 Apr 2014 22:17:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.201
X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o7lRz_aLuGfV for <>; Tue, 29 Apr 2014 22:17:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C22561A212D for <>; Tue, 29 Apr 2014 22:17:18 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.97,956,1389704400"; d="scan'208,217"; a="10093090"
Received: from unknown (HELO ([]) by with ESMTP; 30 Apr 2014 15:07:27 +1000
X-IronPort-AV: E=McAfee;i="5600,1067,7423"; a="273267620"
Received: from ([]) by with ESMTP; 30 Apr 2014 15:17:15 +1000
Received: from ([]) by ([]) with mapi; Wed, 30 Apr 2014 15:17:10 +1000
From: "Manger, James" <>
To: Tim Bray <>
Date: Wed, 30 Apr 2014 15:17:09 +1000
Thread-Topic: [Json] I-JSON Tpic #2: Top-Level
Thread-Index: Ac9kJgHQA2PKPTJXQxSbN+Cu6gpIKwABQBJg
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US, en-AU
Content-Language: en-US
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1154581EB38WSMSG3153Vsrv_"
MIME-Version: 1.0
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, 30 Apr 2014 05:17:23 -0000

Only allowing objects and arrays at the top level was a cause of interop problems.
It was a bad feature, an unnecessary restriction, that we should not perpetuate. RFC7159 and ECMA-404 have taken a great leap to remove it so I don’t want I-JSON to try to resurrect it.

I would be happy to use a JSON function that: required UTF-8; failed on surrogates; failed on duplicates; ignored element order; failed on integers beyond 2^53; failed on floats with more than 22 digits; failed on invalid JSON (eg trailing commas, comments etc).
I would NOT be happy to use a JSON function that: failed when the top-level isn’t an object.
I want to be happy to use a JSON function if it says it supports I-JSON.

James Manger

From: Tim Bray []
Sent: Wednesday, 30 April 2014 1:41 PM
To: Manger, James
Subject: Re: [Json] I-JSON Tpic #2: Top-Level

I’m sorry, but the central idea of I-JSON is to explicitly rule out all the interoperability problems identified in RFC7159: How to produce maximally-interoperable JSON.  7159 specifically says that for interoperability a JSON Text should be an object or array, and the idea of making I-JSON less constraining totally defeats its purpose.  This is just not a reasonable direction to be going.

Yes, it’s perfectly clear to any language lawyer that in ECMAScript, 42 is a first-class JSON text, nobody is disputing this.

On Tue, Apr 29, 2014 at 8:19 PM, Manger, James <<>> wrote:
> Protocols with messages which are objects are better than other protocols, because they are architecturally friendly to MustIgnore policies.
Perhaps we should say a MustIgnore policy applies to all objects in I-JSON; instead of merely making a MustIgnore policy possible via a somewhat tangential rule that the top-level must be an object.

James Manger