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

Anders Rundgren <anders.rundgren.net@gmail.com> Sat, 06 February 2016 02:41 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 C0FBD1A88F0 for <json@ietfa.amsl.com>; Fri, 5 Feb 2016 18:41:38 -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 8g8vcqi1xcG2 for <json@ietfa.amsl.com>; Fri, 5 Feb 2016 18:41:37 -0800 (PST)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 A3ADF1A88EB for <json@ietf.org>; Fri, 5 Feb 2016 18:41:36 -0800 (PST)
Received: by mail-wm0-x22b.google.com with SMTP id p63so50330816wmp.1 for <json@ietf.org>; Fri, 05 Feb 2016 18:41:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=aO+ysJPm3XhPDfjJGK94VfOPwiHNC2mu/CGEfYlfOx4=; b=Ay6alxMhUZVV5k414czccjZdeQRVQA7ErhJvtpEr8yoErXBnIYlfGRllsDy9a07BPC 1xLKuSyschzG3U7F99e8hVDDE4/lDNf4BVrO1fO3San7p5B5jkiP6qeVWn/RgNSqRkrt aqC6edgkZfE/55UukY8wF+bl/UmSd0jvA/kBiKGXOC47dsUJXL/N7baTCLgjfsRokxQ8 e0wdwv1zEyHlapXR8zuXvT7XVfNCLPYOAHuba0Mm27Fj6WkgNwD8bBtYtyYIFTFeHk81 oHk5a+jHShGMqFksPwnWhn02dW0zqpkPRoluEpnc+ZvZ4wCqfxQvu6sKmXqh++xilVGM nVCA==
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:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=aO+ysJPm3XhPDfjJGK94VfOPwiHNC2mu/CGEfYlfOx4=; b=Gyk0Gt7AV4hHSQLr1wGv+d1K4y/SPdDllm0R1LeirChMUs8Oe/lyqSnEOsJqj87BQ1 0DVDkYmHInhuIHHaRk7Wv+vrLfLUr1yN1yO6XO12VOlMz4aeuY8T6WdZLRv6oeXJjFZw JlTktsYZxP6JDY9NxlF9cA3TDIJaZDGwmsw2Q+/vsBFmN7ysgdv5O16ZAB1ptPKh+KLx eiY+DMBBJW1Sq90hAcOvPGduwcuuASk7538gWbSujFL/jHS8+7KkcnhwE/s2a2r1fecn R9Uaa05SHpszryx4TPuwwCUILRFF8dmHn8h9XiYXPjOa4oRchXt+ce/tTzn72SxPbd4N pw1w==
X-Gm-Message-State: AG10YOQwbWvKte3ZYbC8DwWhUcYgf1Xg9j1s1jbWysebBWoCjnjddV7noJuVYJ3KFqBXaA==
X-Received: by 10.194.235.4 with SMTP id ui4mr16465123wjc.177.1454726495272; Fri, 05 Feb 2016 18:41:35 -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 q75sm1210718wmd.6.2016.02.05.18.41.33 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Feb 2016 18:41:34 -0800 (PST)
To: Phillip Hallam-Baker <phill@hallambaker.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> <CAMm+LwhZdAC1nnO=2qqMrgDfXtjtz37cLSac3c_EvQExWoLv4w@mail.gmail.com> <56B4BB58.4010104@gmail.com> <CAMm+Lwj9Z=5S5ASqp2zRoukF0CByohLzUsNZowt=L9TNJsjcvA@mail.gmail.com>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <56B55D5C.8050303@gmail.com>
Date: Sat, 6 Feb 2016 03:41:32 +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+Lwj9Z=5S5ASqp2zRoukF0CByohLzUsNZowt=L9TNJsjcvA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/json/4_9rKmvxN1Tb2lQXzdf6Q89vp0Q>
Cc: John Cowan <cowan@mercury.ccil.org>, Carsten Bormann <cabo@tzi.org>, Tim Bray <tbray@textuality.com>, JSON WG <json@ietf.org>
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: Sat, 06 Feb 2016 02:41:38 -0000

On 2016-02-05 17:27, Phillip Hallam-Baker wrote:
<snip>
>>
>> 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.

I have gradually lost faith in standardization as the best way forward
for stuff that is close to applications.  It takes too long time, and
there are usually multiple roads to (virtually) the same goal.  The IMO
worst thing is that WGs do not generally care about changes in the market,
or the availability of new technology although this could motivate charter
updates and sometimes even abandoning the work-item altogether.

And if you are Google you can do set standards for the rest of the world
which also makes standardization anything but a level playing field.

By building on a Google standard (V8) for JSON normalization (not canonicalization),
I feel quite safe that this concept (rather than my signature definition verbatim),
will become a de-facto standard.  That's perfectly satisfactory for my work which
simply is helping the payment industry converting to JSON.

Anders
https://cyberphone.github.io/openkeystore/resources/docs/jcs.html#ECMAScript_Compatibility_Mode