Re: [Json] On flat vs nested JSON encoding style

Phillip Hallam-Baker <> Fri, 05 February 2016 16:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3B7B01B31EA for <>; Fri, 5 Feb 2016 08:27:55 -0800 (PST)
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 ToACebwD1OqI for <>; Fri, 5 Feb 2016 08:27:53 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 70CAA1B31E5 for <>; Fri, 5 Feb 2016 08:27:53 -0800 (PST)
Received: by with SMTP id cw1so52494015lbb.1 for <>; Fri, 05 Feb 2016 08:27:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=UTkG16+QdMYEWaP0gjOYW7wj2GmlkOFX52iTGab39mM=; b=QUqiyUflJtNMfayx/xrywfUr0+AKBiavTJ4eRKMdF6CvtoZHx6TuwyNtC2CvMEcYTt FOSt7Ts5kqKpUVpQ3gA+hER+PEp5t5V7Qw2R1LBH5S7EWkggtCDcwJeKI/0xZ5V+/ZOA 3PLHNua3Lghsy0vg27NHAB0LY6y9PPt6NeLfmpfNTjpU8fB3CsFbfbemuoU8tFF5BR6Y D9V3IAsfn8+xkulyR7W+0xqRGDjatePeA5souLcT27QdxfwPt1uy2p8btCByGveeQ9qe kXSPPsUR97Q4IGhWT/uRPIMunR39lZxJ+7tfeeu5z73gU9kGzTkTA79kHkcuvkiamGhZ 9bng==
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=UTkG16+QdMYEWaP0gjOYW7wj2GmlkOFX52iTGab39mM=; b=bOih84kuKfhK4VVsntRKCDYF0wlFCChYnImLDweR3xNk5h8VErxfVrUnRiJmZpr2r8 jDFCJN37+huZ1x9XurUJa/+jr8kF71lhtn7h5+vwkETt0G/ACxowgfIB93P50oiqjc/S 2CNJiixBAxFPU1/muESGu6Ayu+OoNhntf90Sk3CtjaQYZQcAfHiVwkqMrwTheC1XWZJP pbbuikQeC2gWkHwfzaI9pIctSNr3UXluG4MOmjGS0PTTtXiXJCz6MU9XTZGrVqqz1W4g g8TS/bkOVwYKtIQD8uosKws5NyuZt+q3WvqQizXYelJIdfmSINEoKbevXXFTaOu4lUXH Zqvw==
X-Gm-Message-State: AG10YOTDdQnYYfo5tP8Vbb/mz/YmrkB3zMh4YPUfSp2A1M2x9QoQYpdQjT1JpuDGmzPCN/NzdNiDZl/qk25lOA==
MIME-Version: 1.0
X-Received: by with SMTP id zf4mr6365711lbb.58.1454689671664; Fri, 05 Feb 2016 08:27:51 -0800 (PST)
Received: by with HTTP; Fri, 5 Feb 2016 08:27:51 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Date: Fri, 5 Feb 2016 11:27:51 -0500
X-Google-Sender-Auth: DFgnnMX-B-HUyGrLlLu1tDHVBKU
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Anders Rundgren <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: John Cowan <>, Carsten Bormann <>, Tim Bray <>, JSON WG <>
Subject: Re: [Json] On flat vs nested JSON encoding style
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: Fri, 05 Feb 2016 16:27:55 -0000

On Fri, Feb 5, 2016 at 10:10 AM, Anders Rundgren
<> wrote:
> On 2016-02-05 15:01, Phillip Hallam-Baker wrote:
> <snip>
>> What you are arguing for is that you want to write your structures like
>> this
>> struct fred { int a, int b, int c}
>> { "a" : 1, "b" : 2, "type" : "fred", "c" : 3}
>> Now you might think that is a reasonable way to present the data in a
>> spec but most of us would say that it is hard to follow. The important
>> information of the type of the structure is buried in the
>> serialization stream.
> I fully buy into the efficiency aspect of the nested encoding style (which I
> honestly had never thought of), but when it comes to "hard to follow",
> predictable
> serialization a la ES6 seems like a more universal solution since this also
> sucks:
>   {
>      "city": "Paris",
>      "name": "John Doe",
>      "country": "FR",
>      "zip": 245333
>   }
> ES6 serialization and the nested encoding style scheme can easily be
> combined,
> hopefully bringing out the best of both worlds!

There are probably valid use cases for a canonical serialization
format. And that is probably more viable in JSON than in XML.

However, I am very very skeptical of the benefit of canonicalization
for digital signatures. I have been in countless meetings where this
has been asserted as a requirement and I have never once heard a
plausible argument. Emit the bits then sign them.

BTW, yes I am working on a way to avoid the wrapped Base64-url encoding:

This is part of The Mathematical Mesh which is described at

I have a scheme to get rid of the Base64-url encoding in JSON as well.
But the result isn't JSON, it is JSON-B. Which is simply JSON with
some additional code points defined for sending binary data as
length-data chunks.

The reason I want this is that I use cryptography at multiple levels
in the Mesh and I want to use the JSON data model as my only encoding
regardless of the layer I am at in my protocol stack. You can't meet
requirements for meta-data protection and end-to-end security with a
single layer of crypto. A 33% increase in data volume for each crypto
pass is unacceptable.

So I have these schemes, but they are not JSON encoding. I call them
JSON-B, JSON-C and JSON-D. The simplest, JSON-B just adds binary
encoding for numbers and length delimited strings and binary data.
JSON-C adds tag compression and JSON-D adds in more floating point
formats such as you might need for scientific data.

I suggest that you write up the canonical serialization as a separate
draft and get it an assigned content-type. We could call it JSON-F
(for fixed) or something like that.