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

Phillip Hallam-Baker <phill@hallambaker.com> Fri, 05 February 2016 14:01 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D041B3918 for <json@ietfa.amsl.com>; Fri, 5 Feb 2016 06:01:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ze27lxlCPxpS for <json@ietfa.amsl.com>; Fri, 5 Feb 2016 06:01:58 -0800 (PST)
Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A73EA1B3917 for <json@ietf.org>; Fri, 5 Feb 2016 06:01:57 -0800 (PST)
Received: by mail-lb0-x231.google.com with SMTP id bc4so49988448lbc.2 for <json@ietf.org>; Fri, 05 Feb 2016 06:01:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=9bCHkAD4GiazVcxz0bxeDFcLbJVjrnH5Y0POfK6EPkw=; b=PQFrmyfzSyPHtom62qakf9vQ9L992rO8n+DtN4u6Xq/UeyoARet+iOBcfrNenlcIjm NOYibiHUPAGtseXnfozY9MFrb8lw+4jZnPdgwTaOJeU3FH9vgC0cirM5CpLfWfnoWcvZ NyN57Wt6SizgTuaxfUqLCJHFoSMfqES1Slz9KV25u52xUK5Swzp/bdXm4TZF6cP+RpKB KZNyS6bOKuUw8o6Haya1Gej2ik2Q1EYQNlO8rCP5gm945j4XeK8mSYWllLZPhCwPi/3H gXqCsR6odM6+JH4SGKTr4ql4YMrRexg4QlGM0i0CUT7U3T02qE7wFCQ5pH43szc59svU 1i4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9bCHkAD4GiazVcxz0bxeDFcLbJVjrnH5Y0POfK6EPkw=; b=e0HSGRmp6/inRx+O4rq6pr6lAbjnKewlKs2P/KhYbmsq6QMyTdOZ8gAnYf8ZYEknFl vA4NDZYlXQrp7LSJHtk4/t32E9LlpVj7RfMOzpCERhITe5y6phFwnO8kXmKLGzYiojBA IVLko/UwySIS9tQ3TJSSx3Z8j0lKaTdVGDUFHahl1sbgDJAIH/Rak9HJft3SU3YMO7X5 08pgsGBMTT1qsw8Ib+QfGKNakcmarvlhRFMJvCCCEWlF1cr2JBJOd8/Z+mNn5iPRiXLg 2TllOJHtvToo1eRg4mWUbYdHwldGV3g2QuuY1qNPfbkRtgoQiSiF5NUwaQNeKVY4eyvq eLYQ==
X-Gm-Message-State: AG10YOTaLcN0HAzFTk5VQuZMKDYJgzGvOAbgemyNo5nWZ/E0s5leyZXOiYKS9t16azyib9msTIX4MAjlXbyurQ==
MIME-Version: 1.0
X-Received: by 10.112.141.97 with SMTP id rn1mr6446061lbb.80.1454680915872; Fri, 05 Feb 2016 06:01:55 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.49.80 with HTTP; Fri, 5 Feb 2016 06:01:55 -0800 (PST)
In-Reply-To: <CAHBU6iu9peh7YkPV4SsRmtmuEjwoQH_Kg+Wf3qtvBccT=iChRQ@mail.gmail.com>
References: <CAMm+LwirhVcmUkdfyA3WKe_W747JTWNF1Ht2Nr8NJdDxOFCJOw@mail.gmail.com> <56B36D15.1030306@gmail.com> <56B370A1.1050508@tzi.org> <56B373B8.7040305@gmail.com> <20160205001717.GC2997@mercury.ccil.org> <CAMm+Lwg4iqKtUjX+gw2zMu6A-fRc7_MRT14R3n670gBzMtdP9Q@mail.gmail.com> <56B43FCE.6080408@gmail.com> <CAHBU6iu9peh7YkPV4SsRmtmuEjwoQH_Kg+Wf3qtvBccT=iChRQ@mail.gmail.com>
Date: Fri, 5 Feb 2016 09:01:55 -0500
X-Google-Sender-Auth: QWJHPjQ3BUVjGOlynyvAkyQVeoE
Message-ID: <CAMm+LwhZdAC1nnO=2qqMrgDfXtjtz37cLSac3c_EvQExWoLv4w@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Tim Bray <tbray@textuality.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/json/di9QRrceXNoAiFy5BYc6goPZ2uQ>
Cc: Carsten Bormann <cabo@tzi.org>, JSON WG <json@ietf.org>, John Cowan <cowan@mercury.ccil.org>, Anders Rundgren <anders.rundgren.net@gmail.com>
Subject: Re: [Json] On flat vs nested JSON encoding style
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Feb 2016 14:02:00 -0000

On Fri, Feb 5, 2016 at 2:35 AM, Tim Bray <tbray@textuality.com>; wrote:
> Well, over at AWS, I’ve just helped launch an experiment in doing things at
> a large scale exactly the way PHB recommends against :)  Check out our
> “CloudWatch Events” JSON at
> http://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/CloudWatchEventsandEventPatterns.html
>
> We have millions & millions & millions of these flowing through the pipes
> already, with many more to come.

If you use a particular tool and that is the only one you understand,
you won't see the problem.

This is a standards organization. So the architecture should impose
the fewest constraints on implementation as possible.

Very small changes in implementation can make a huge impact on
implementation. The reason ASN.1 is hated with a passion by pretty
much all crypto folk who have implemented it is one line in the
definition of DER encoding. The use of definite length encoding over
indefinite length had virtually no impact on X.509v1. Either could
have been chosen as canonical. The one they chose has a dramatic
impact on complexity of the implementation in X.509v3.


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.

What is hard for a human to work out imposes unnecessary constraints
on computer implementations. It makes JSON a special case for no good
reason.

I have a tool that can serialize/deserialize to JSON, ASN.1 or XML
from a schema that is essentially just a description of the data types
to be passed on the wire. It doesn't support unrestricted XML and
implementing PKIX requires the schema to be decorated with additional
information to define encoding details.

The reason I like JSON is precisely the fact that right now, it does
not require any decoration and the only constraint it imposes is that
the tag to describe the data structure precede the data being
described.