Re: [Json] Call for WG Consensus to Adopt I-JSON as a WG Item in the Charter

Nico Williams <> Mon, 17 March 2014 15:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 014351A0413 for <>; Mon, 17 Mar 2014 08:21:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DDcd_F02HnR9 for <>; Mon, 17 Mar 2014 08:21:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4A5051A042E for <>; Mon, 17 Mar 2014 08:21:44 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 744F92007F124 for <>; Mon, 17 Mar 2014 08:21:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type;; bh=GilMqVEAcEtU8nQ9HdLp yFJGe9Y=; b=UomvJZMnZfHn9sJgCa6CrvLEpsohKNVJIXgWrZJWKRzFeiiOSpL3 bTo70OqKBu+kWNakgppSFTRFdp2u2HvkmnRdKa22uE3WNdnj1xqB841Vt/J/FVm2 kNP/A+rRP61sYkwjg64TSW77KvFZFVl0UklxIPkkbclDPGH14F7ctlY=
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 299562007F120 for <>; Mon, 17 Mar 2014 08:21:36 -0700 (PDT)
Received: by with SMTP id b13so4792388wgh.5 for <>; Mon, 17 Mar 2014 08:21:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kkKFtx2/Eia2P2Apg6sZn93V4cUlcUOaoE2ayW+tcGY=; b=KGofsOY/YXTzyfDeXnUXO6eWpO7T8loeXALII1zg8MO1Oerw+0SKTMpOvsucBd4WS7 8di6Iq3ukw2omseqhUEYw1v0A4eX6eEgWWljr9Wjina/8VzkdhiQkIbIzgZwNDmn34FX 5zrRhbXtLXozfEjGuTNhTFl2u2cNUneXX4oozuDLoUa3KJQ1rS/m1EVdI99fzBdBWJhw jeYxZlkP2jqrlJ0zQos4e4dAGYNzEq7bRe31IZ6gVeZl2sxlSU5En5/S/ABC1tcMUITg 4b+MDmnWvsmfP5UDvWMgiCELsnDf3EWhi2YFNDaqk4dppHtnRqeFnWVQTPdoseoduUnN 4Jiw==
MIME-Version: 1.0
X-Received: by with SMTP id kv8mr6522920wjb.41.1395069694915; Mon, 17 Mar 2014 08:21:34 -0700 (PDT)
Received: by with HTTP; Mon, 17 Mar 2014 08:21:34 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Mon, 17 Mar 2014 10:21:34 -0500
Message-ID: <>
From: Nico Williams <>
To: Phillip Hallam-Baker <>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [Json] Call for WG Consensus to Adopt I-JSON as a WG Item in the Charter
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, 17 Mar 2014 15:21:47 -0000

On Mon, Mar 17, 2014 at 6:56 AM, Phillip Hallam-Baker <> wrote:
> On Sun, Mar 16, 2014 at 11:51 PM, Nico Williams <>
> wrote:
>> My main complaint is with the recommendation/requirement that JSON
>> texts be objects at the top-level.
>> Instead I would say that if there's reason to need to signal "schema"
>> metadata in-band then a) application should specify how they do that,
>> b) here's a few ways in which they might, and all their pros and cons.
>> Note too that there are many apps where there's no need to signal
>> schema metadata in-band because they always have some way to
>> communicate relevant metadata out of band.
> I have no problem with this as a convention in a protocol. But I don't see
> the need for that restriction in I-JSON.

If the purpose is to signal schema metadata then I'd like to explore
other conventions and go for a "you must provide such metadata"
statement in order to make yours an I-JSON usage.

> In a protocol design the spec is going to say something like 'the encoding
> is in the I-JSON subset of JSON'. Then its going to describe the format of
> the data which for a protocol is almost always gonna be an object per
> message at the top level. Though it could be an array of objects if multiple
> requests per message are supported.

Right, imagine wrapping an array of objects in an object just to
denote schema metadata.  What a pain.  You're probably streaming the
array, so now you gotta add an object around it -- and remove it -also
in a streaming manner- on the parser side.

Or perhaps you have a sequence of objects to return... should you mark
up every one of those objects?  While streaming them?  More pain.

We should consider how this markup happens.

Incidentally, we could say that the first text in a JSON text sequence
should denote schema metadata for the rest...  That would not be so
painful.  (although it would still interfere with existing usage).