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

Phillip Hallam-Baker <> Thu, 04 February 2016 15:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EEEA71B3088 for <>; Thu, 4 Feb 2016 07:58:14 -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 IYIBBQzOSE6A for <>; Thu, 4 Feb 2016 07:58:14 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B81CE1B31FE for <>; Thu, 4 Feb 2016 07:58:13 -0800 (PST)
Received: by with SMTP id m1so39787505lfg.0 for <>; Thu, 04 Feb 2016 07:58:13 -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=RKoMh8XVdjrUEFHy5rvxKHipG+YrQgPNzYwqpZwVl/M=; b=fQkDag6iMRMRh6poK/bS7dBdAaqXlXgXOPdqExpEYkpJ6Yo+1I5KtU1hSY8ZgerSrn dzo/wMs9I4u6BLO9aGo1PHAjVNTTM3pbcUBn3W3B4lUfwhOvIHfd1OOcUGKCMfT4TzA5 B9R/lK6ufuooSbvtwXIa2jK/9N1DLFDWt13v8cmn0qs/+nqfeWjTnMKo072168pn7725 WQ5RFYvI6SggXMfOFhxpFkvZnV0tkTufBnlG2vH7FDq+Y79IZ6FZ/leY0lhq03uNrnOy 1glGNeic3XBquAhxv6rU2T2spUlYGmGkASp/SoE/mGYLbng/Bsg5Umz+TNQjoFIZ5zDh d9ZA==
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=RKoMh8XVdjrUEFHy5rvxKHipG+YrQgPNzYwqpZwVl/M=; b=DK0IGUFS/+cnJuptej0CogbUhIieOLfJcxxiswEbokfOuGYWjaTjANFrOi+wxFp+pe RV5+5cq4do+d+b0bhE099BkIuK2YTtm0TmySA7X9j6+63PWadiLPtmPg2rwZLtLSGxhC 9KCI3rmfSJEOGzOOunZeMNiuLoj3Ckvu+Z0aGAba5U1A6EhsPYQpFOqFo2iskhhB86eS Quo3hE16uIK7l/Pfr4i2OYZlrFxl7AJupYUZ9PgjiM/iun4kldHidJf8QbGpsREtPEP1 JMO9QTU1rKqhvvvoLQvjUJXL8hxTIhh9dRDNe0O5iof9ZI3qgu8smcetSWY5k4Y40YQH wpDw==
X-Gm-Message-State: AG10YORTCf9XU1uXgFHz90ahEIU/m/n0zjhyTtXKVCuMY5UXYKcG0N0xwgtraaii7j2TApJ8IlprKd8n1cqhZw==
MIME-Version: 1.0
X-Received: by with SMTP id 100mr3771565lfw.153.1454601491948; Thu, 04 Feb 2016 07:58:11 -0800 (PST)
Received: by with HTTP; Thu, 4 Feb 2016 07:58:11 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Thu, 4 Feb 2016 10:58:11 -0500
X-Google-Sender-Auth: 1nHtrsHsjan07Lk2nQC1mOjl4-0
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Carsten Bormann <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: JSON WG <>, Anders Rundgren <>
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: Thu, 04 Feb 2016 15:58:15 -0000

On Thu, Feb 4, 2016 at 10:39 AM, Carsten Bormann <> wrote:
> Anders Rundgren wrote:
>> Anyway, isn't CBOR what people are targeting for constrained devices?
> Yes, but the desire to be able to do sequential (as opposed to
> DOM-based) processing goes beyond constrained devices.

Exactly. Every device is constrained when you send it a big enough problem.

I did think of mentioning CBOR but for another reason. A lot of times
you are going to want to apply a protocol that has already been
designed for JSON to a constrained device. This is one of the reasons
I argued that there should have been a WG to design an efficient
binary encoding. My objective was to be able to indicate the 'binary'
version by specifying application/json-b without having to make any
other change.

I think it likely that people will want to do the same with CBOR. But
that is a lot harder if doing so requires the structure of the parse
tree to be 'messed about'.

I would much rather that we have a style guide that guides people
towards an approach that is flexible.

Carsten's example does demonstrate a more general version of the same
problem. But I don't think it is quite as critical. Because what I am
talking about here is mapping JSON data to objects in strongly typed
languages. And all the strongly typed declarative languages I am
familiar with (and I know a very large number) have a type system that
can be reduced to text label.

[Yes, I did functional programing, we did Orwell. But I have yet to
unpack a widely used open source tool to find that it was written in
F#, Oberon, or any other from that family]