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

Anders Rundgren <anders.rundgren.net@gmail.com> Thu, 04 February 2016 15:24 UTC

Return-Path: <anders.rundgren.net@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 A9F551B3163 for <json@ietfa.amsl.com>; Thu, 4 Feb 2016 07:24:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 qJoYYSB8QiZ1 for <json@ietfa.amsl.com>; Thu, 4 Feb 2016 07:24:27 -0800 (PST)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 D89481B3164 for <json@ietf.org>; Thu, 4 Feb 2016 07:24:26 -0800 (PST)
Received: by mail-wm0-x229.google.com with SMTP id 128so32116502wmz.1 for <json@ietf.org>; Thu, 04 Feb 2016 07:24:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=Hj5SQo8ZKqC9Qo4QickQ/GEEbQI3B/OegEaEuDrPrA8=; b=XP3pWz5FES4CKR3IPaKvA66+3GoTjw7PFMyl8HkUSxwugU3IPi+jzn5j9dqdn5jBiz Xyz/7DwyTiV5qfWqf7FApFT33/to1qEs/TAYMItxiqB+PK2hp4qiBiXDGwNfx/yZ+knG DCtH27KJdua6/ZE21V11LN9FJe4LfzKV3/bjW3/NZ3kTIJEDfVQB2yJaYVXR0UaGcB36 wuUcni8reOsrVezS3/gwVe89Vbvpwi70jTKP2z/12+n7D+2QCcNvsvwcDSvHNL1SDeS9 Is2gN61qSLi23Zcpl84S8IeZPX2YcZC2z2Tg/KycBcbMQ+q5/9B+73EJ+7n/lXBiEPCr LxeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Hj5SQo8ZKqC9Qo4QickQ/GEEbQI3B/OegEaEuDrPrA8=; b=TqEkJaucaRfOUxURRmldhNiOC5tg0setsd3pnjJS4nIIVgcESd224NNoabBUb0zOy6 SYRebXnyl0X7zchjL+9j2ddYXUe17SwmdNXiZfQIj6XIRbzJT+2ceEORfKDkDLfd8ClN kcEKuGO9qG0O/YvMu6ZdPXSMa7KbT9Wvbkb+4wW6jMJWvCLoZI9vGJs2tAk6R7fc3nsI N/J7zAcx8Kt6JpkzVZlzYXC7zaDhQNlMfbhrPY6eksQgIkjDvi2AXDyjDsPiL1DWlPuD mplNNsRyxrkSPs4p9IoAUGh+ON9RnYxPVhFHFREoiMjIzBn6aUxZrzaoosu/dVwQYvoy 3paA==
X-Gm-Message-State: AG10YOR7cvHec0rssCZGJtmNMQ39W7/mVMb4blP9BHC/sFpkrWIpXHowPoy1iGiWj6X8xA==
X-Received: by 10.194.119.161 with SMTP id kv1mr8845077wjb.135.1454599465481; Thu, 04 Feb 2016 07:24:25 -0800 (PST)
Received: from [192.168.1.79] (9.197.130.77.rev.sfr.net. [77.130.197.9]) by smtp.googlemail.com with ESMTPSA id lc3sm11801857wjb.7.2016.02.04.07.24.24 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Feb 2016 07:24:24 -0800 (PST)
To: Phillip Hallam-Baker <phill@hallambaker.com>, JSON WG <json@ietf.org>
References: <CAMm+LwirhVcmUkdfyA3WKe_W747JTWNF1Ht2Nr8NJdDxOFCJOw@mail.gmail.com>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <56B36D15.1030306@gmail.com>
Date: Thu, 4 Feb 2016 16:24:05 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <CAMm+LwirhVcmUkdfyA3WKe_W747JTWNF1Ht2Nr8NJdDxOFCJOw@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/json/xm2CYjtgWqJ26gpBxgEcI569frw>
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: Thu, 04 Feb 2016 15:24:29 -0000

On 2016-02-04 15:59, Phillip Hallam-Baker wrote:
> I think it would be helpful to have a style guide to encourage styles
> of JSON use that impose the fewest constraints on
> serialization/deserialization design.

By pure coincidence I wrote this (somewhat related) paper today:
http://webpki.org/papers/AppNote-XML2JSON-Migration.pdf

Using your nested design, the outermost property could be something like
"https://json.standards.org/payments/PaymentRequest"
Not ultra-pretty but certainly workable.
Using JCS an embedded signature would preferably be applied to the outermost object.

Anyway, isn't CBOR what people are targeting for constrained devices?

>
> For example, lets say that we have a protocol that has two types of
> request, A and B. There are two common ways that this can be
> represented in JSON:
>
> Nested style:
>
> { "A" :
>     { "field1" : "value1", "field2" : "value2", "field3" : "value3" } }
>
> Flat style:
>
> { "Type" :"A" ,  "field1" : "value1", "field2" : "value2", "field3" : "value3" }
>
> They both look similar, the only difference is that there is an extra
> layer of nesting in the first case which means that the label "A" will
> always precede the data it describes. This isn't the case for the
> second which can also be written :
>
> { "field1" : "value1", "field2" : "value2",  "Type" : "A" , "field3" :
> "value3" }
>
> While the issue comes up with requests, it isn't limited to requests,
> it can happen anywhere that you have a need to tag an object to
> describe the type.
>
> If you are using a scripting language, you parse the data to a DOM
> tree and which is the in-memory representation of the data.
>
> But those of us who use strongly typed languages like C# and Java
> don't work of DOM trees. We map the data to objects in our
> implementation language. and we type check and validate all our inputs
> before we begin processing. Because that is best practice for
> minimizing attack surface from an invalid input.
>
>
> Nested style allows us to build fast, single pass deserialization
> tools that require no additional buffering. A constrained device can
> build the parse tree on the fly without buffering a whole message
> before it starts processing.
>
> Flat style requires us to buffer the data and do a two pass approach.
> It is very much less efficient as a result.
>
>
> Comments?
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>