Re: [Json] I-JSON Topic #2: Top-Level

Nico Williams <nico@cryptonector.com> Wed, 28 May 2014 21:54 UTC

Return-Path: <nico@cryptonector.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 864D71A06BD for <json@ietfa.amsl.com>; Wed, 28 May 2014 14:54:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.043
X-Spam-Level:
X-Spam-Status: No, score=-1.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 wQegyjkUhxl9 for <json@ietfa.amsl.com>; Wed, 28 May 2014 14:54:06 -0700 (PDT)
Received: from homiemail-a105.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 384CA1A0272 for <json@ietf.org>; Wed, 28 May 2014 14:54:06 -0700 (PDT)
Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id 877E52007D834 for <json@ietf.org>; Wed, 28 May 2014 14:54:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=orm2L+mT1o/Vi/qQO0sC 6WQp7FI=; b=DlYbMXIXRwgPiIw9KdHgzZmNR24AoFjFLTCGZnrcVzfx6f0zlzzH x7Dp4qUUSCLi2dZNZgLoP2wKOh2VEn8SnFW/d1bHCdZ/gJ80WdVICSa+pzXhSJyu h9vmCsmmxQOqznzn2gBI+q7gGsQa+thuphRAV72v8q319DGntm3wPl0=
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPSA id 3CD0D2007D832 for <json@ietf.org>; Wed, 28 May 2014 14:54:02 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id a1so11651084wgh.15 for <json@ietf.org>; Wed, 28 May 2014 14:54:01 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.120.68 with SMTP id la4mr3762715wjb.40.1401314041048; Wed, 28 May 2014 14:54:01 -0700 (PDT)
Received: by 10.216.29.200 with HTTP; Wed, 28 May 2014 14:54:00 -0700 (PDT)
Received: by 10.216.29.200 with HTTP; Wed, 28 May 2014 14:54:00 -0700 (PDT)
In-Reply-To: <CAOXDeqrXet967enqiqK-Yx5PRT7dW+6t=TxN0=o+W8bWGSpg-w@mail.gmail.com>
References: <535EB119.4000908@cisco.com> <53861E05.9070208@cisco.com> <CAOXDeqrXet967enqiqK-Yx5PRT7dW+6t=TxN0=o+W8bWGSpg-w@mail.gmail.com>
Date: Wed, 28 May 2014 16:54:00 -0500
Message-ID: <CAK3OfOh_Y3EXhnjr8Tz+7T4irNwsF9MztXEavNAd0ehmjY0Aow@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Matthew Morley <matt@mpcm.com>
Content-Type: multipart/alternative; boundary=089e01160098a2ba9504fa7cd9b6
Archived-At: http://mailarchive.ietf.org/arch/msg/json/gJMegKmboB_cDsAJdXBVMWc-Thc
Cc: "Matt Miller, \(mamille2\)" <mamille2@cisco.com>, json@ietf.org
Subject: Re: [Json] I-JSON Topic #2: Top-Level
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: <http://www.ietf.org/mail-archive/web/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: Wed, 28 May 2014 21:54:07 -0000

On May 28, 2014 3:57 PM, "Matthew Morley" <matt@mpcm.com> wrote:
>> Does anyone have additional arguments to make for or against what
>> constitutes an I-JSON top-level?

[...]

> With the top-level restriction in place, but without a standard structure:
>   - non-structured data must be encapsulated: {"result":42}
>   - structured data would be ambiguous: {} -or-  {"result":{}}
>
> If you are in a system that uses function composition, it means you need
to bake this into your expected types/categories, or have a design that
handles and hides the encapsulation/decapsulation steps from the
composition reasoning portion. I don't have (or plan) such a system, so
this is outside my expertise, but imagine this being a limitation for those
that might have/want such a system. (?)

Thanks for capturing this issue so clearly.  Yes, superfluous encapsulation
is obnoxious, particularly in systems with computable units not all of
which produce the blessed output types.

Remind me, what do we gain from this?  Interop with old libraries that
probably don't conform to I-JSON anyways and which stand a good chance of
being fixed soon enough that this top-level restriction ends up buying us
nothing a year hence.  Please re-think this!

Nico
--