Re: [Json] Consensus on JSON-text (WAS: JSON: remove gap between Ecma-404 and IETF draft)

Phillip Hallam-Baker <hallam@gmail.com> Tue, 03 December 2013 00:07 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 8C7671ADFAA; Mon, 2 Dec 2013 16:07:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 Fun32GAmZcxk; Mon, 2 Dec 2013 16:07:34 -0800 (PST)
Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id DC7021ADF9A; Mon, 2 Dec 2013 16:07:33 -0800 (PST)
Received: by mail-wg0-f51.google.com with SMTP id b13so9976337wgh.30 for <multiple recipients>; Mon, 02 Dec 2013 16:07:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gnhXWov9NSYYriybXeROk3XfdUglPfoUkOyEXzjDznY=; b=E8b1QZxy+epsg5KiVJN/UJEySWGCkvxsFHYk8TUuzluCqgzrlydjOkeGsxa1q/39mO HbFURjj0Uy8+4LmiJONHVMrVgj8xmJSSJDF7ARzE+CF2PaMWQ9XjujTc1waB5Q3UZIoG hWnPGppVHJSJW5412CaplxV4ysrm/tczEkYETTU17Pbj1rxicDREx/dD1I0Hd1JsdvdT t1hOgZ/SIMgrcreoU6/AXtoYpyKneR1vAXrgL64wNvCHBG+mK2TGNq8KeED4rVAFc2fT EqaikT2dm/1PsQL71zvpewy3d+5euWwetEXjG5sxPENMPiVIWRiSnAlZw4DtnSwMkVHS 2ysQ==
MIME-Version: 1.0
X-Received: by 10.180.108.97 with SMTP id hj1mr20602587wib.59.1386029251010; Mon, 02 Dec 2013 16:07:31 -0800 (PST)
Received: by 10.194.243.136 with HTTP; Mon, 2 Dec 2013 16:07:30 -0800 (PST)
In-Reply-To: <20131202224802.GY21240@localhost>
References: <CADnb78h8AjPcQLOCwNm0Pt3pObh6uFV5+zy0c_YU6B-u4MtY1Q@mail.gmail.com> <AA45B3C6-1DC5-4B1E-8045-C9FE76022584@vpnc.org> <C93F89AD-81D2-4489-ADC4-AB05A5B10883@cisco.com> <CAHBU6itgE9=WP+c0oXt1W647b1zz+N6+4ZqRa63Ve91TUsGzTA@mail.gmail.com> <CANr5HFVhG5SNhW4yJxDicvFman94FaNi8UZHhcpQbH6AG6pfQg@mail.gmail.com> <CAHBU6it-yHeHVY+3EFvPd0pVu4uLLdH3Gmz53LL4DZWJSyyUuQ@mail.gmail.com> <6C28E0DD-5E45-42DB-A915-795EE0A489CC@w3.org> <CAMm+Lwh-VNdtTRj6=keGMWbANDqQKbj6CODtwe1rquU8H7+32w@mail.gmail.com> <20131202224802.GY21240@localhost>
Date: Mon, 02 Dec 2013 19:07:30 -0500
Message-ID: <CAMm+LwhZwgrD6U=z+rEAyYD-9TK0ZNdFbmNrVSTRAdB5M2TPCQ@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: multipart/alternative; boundary="e89a8f3bafef27a98804ec961565"
Cc: Tim Berners-Lee <timbl@w3.org>, IETF Discussion <ietf@ietf.org>, JSON WG <json@ietf.org>, Alex Russell <slightlyoff@google.com>, Tim Bray <tbray@textuality.com>, "Matt Miller (mamille2)" <mamille2@cisco.com>, "www-tag@w3.org" <www-tag@w3.org>, es-discuss <es-discuss@mozilla.org>
Subject: Re: [Json] Consensus on JSON-text (WAS: JSON: remove gap between Ecma-404 and IETF draft)
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: Tue, 03 Dec 2013 00:07:36 -0000

On Mon, Dec 2, 2013 at 5:48 PM, Nico Williams <nico@cryptonector.com> wrote:

> On Mon, Dec 02, 2013 at 04:30:09PM -0500, Phillip Hallam-Baker wrote:
> > Since we are talking about a serialization format, the distinction
> between
> > unordered sets and lists cannot occur at the wire level and this is where
> > we need interoperation.
>
> But it can be part of the on-the-wire description.  See below.
>
> > One of the things I think we have learned from JSON is that a
> > self-describing format only needs to specify the abstract type of the
> datum
> > and not the representation.
>
> Self-description is a continuum.  Some ASN.1 encoding rules can encode
> quite a bit of a schema on the wire -- clearly there's a point at which
> the resulting redundancy causes problems.  But it's also true that
> having a large subset of the schema in the serialization can be useful
> (e.g., for generic "dump" tools).
>
> Given the prevalence of languages like Python, a "set" type will no
> doubt seem useful to some!  Heck, the ability to use non-string values
> as keys (names) for objects would be nice too -- anyone who's spent much
> time with Python and JSON has wished for these things.  JSON alone is
> insufficiently expressive for "pickling" Python values; JSON with a fair
> bit of convention layered on gets closer to being good enough for
> pickling Python values.
>

Well that is a rather different situation, the language allows for
polymorphic typing and does not have a clue what the native data type of
the entries it exchanges is.

I agree that there is a utility in that information for pickling data
values but it is not an approach I would like to see in an application
protocol.

The way I would approach this if necessary would be to add in a tag that
could be used to annotate the data with additional type hints.



-- 
Website: http://hallambaker.com/