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

Matthew Morley <> Wed, 28 May 2014 19:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 62D921A00EA for <>; Wed, 28 May 2014 12:57:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vSboYFfSPM_8 for <>; Wed, 28 May 2014 12:57:09 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7D2421A007D for <>; Wed, 28 May 2014 12:57:07 -0700 (PDT)
Received: by with SMTP id a108so19659459qge.11 for <>; Wed, 28 May 2014 12:57:03 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eCwoObJlXNIAdEv+SUSUv4e+MgskyfinCaibDlPtXtU=; b=maW6tRWhkSNhN0aGRUj0WcwztS8SyqwBubVARmeUekQD7/lOuMq5zXL1+ezDxgRngr WeYDffMMfmsZAjCBu6boMnxT9EvBciqmnrn/usTV2b7Iwe7q/gmCtU0+YpQMXUwazYt9 uQfHIfDue4lf/nqBEV/L/ld42PJVaxNMBwBN+0uM2QuGbLYrk0aVGr+hbSLMn+FkUy/H jyu9ViIne5tP5B+T7XzfYAXH+nRJYF1gjSV2pI75o4pWuZA7LRXhn+Fn4Vf45I8dSnJn QBX02acKsWe8SqdZY/c+3DIj8dLHJp5K/piX2vKjnwM0FDiR0CvC8OYhAAXv8DGX+jHR iY+A==
X-Gm-Message-State: ALoCoQltGf438qyyVy3PGu3Ror+67UWMBsFAHYeBMZMX+ldJUXow9khbvp9xZaHnZ0MSNDw3yC1h
MIME-Version: 1.0
X-Received: by with SMTP id w18mr2797341qax.21.1401307023321; Wed, 28 May 2014 12:57:03 -0700 (PDT)
Received: by with HTTP; Wed, 28 May 2014 12:57:03 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Wed, 28 May 2014 15:57:03 -0400
X-Google-Sender-Auth: AY2RX7xWzl0kuncM7dCJPIh05zA
Message-ID: <>
From: Matthew Morley <>
To: Matt Miller <>
Content-Type: multipart/alternative; boundary="089e014948fa58e46804fa7b3715"
Subject: Re: [Json] I-JSON Topic #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, 28 May 2014 19:57:11 -0000

On Wed, May 28, 2014 at 1:33 PM, Matt Miller <> wrote:

> Hash: SHA512
> Hello All,
> After another round of discussion, it appears there is rough consensus
> for restricting the top-level in I-JSON to object or array.  The
> Chairs note consensus is rough here.
> Does anyone have additional arguments to make for or against what
> constitutes an I-JSON top-level?

No additional arguments from me, though I would prefer to see all types
supported at the top level... but instead I'll post an observation from the
RPC problem space.

Given that I-JSON limits the top level to be an object or an array, then
systems that generate results which are not those structures, therefore
require encapsulation to be communicated at all.

Meaning I can cannot respond with 42 and consider it a valid I-JSON (or

Effectively this means all response data for such systems should be
encapsulated, including objects or arrays, into a known response structure
of some shape. The JSON-RPC specification does this with 'request' and
'response' objects, exactly for this reason and the desire to convey errors
and other data.

Thinking about RPC style protocols where local methods may be executed,
with the method and params then turned into I-JSON, then shipped off to a
processing end point, decoded, processed, re-encoded, sent back, decoded,
and finally received to be handled and understood.

In practice this means:
  - If the actual result of calling sum(40,2) is 42.
    - at the I-JSON layer it must look something like: {"result":42}.
  - If the result of calling object() is {};
    - at the I-JSON layer it must look something like: {"result":{}}.

With the top-level restriction in place, but without a standard structure:
  - non-structured data must be encapsulated: {"result":42}
  - structured data would be ambiguous: {} -or-  {"result":{}}

If you are in a system that uses function composition, it means you need to
bake this into your expected types/categories, or have a design that
handles and hides the encapsulation/decapsulation steps from the
composition reasoning portion. I don't have (or plan) such a system, so
this is outside my expertise, but imagine this being a limitation for those
that might have/want such a system. (?)

Though again, a limitation that can be overcome with standardized


Matthew P. C. Morley