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

Nico Williams <nico@cryptonector.com> Mon, 02 December 2013 22:48 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 16C2B1ADEB5; Mon, 2 Dec 2013 14:48:12 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 B1YyFJkOpa2W; Mon, 2 Dec 2013 14:48:10 -0800 (PST)
Received: from homiemail-a106.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 508DB1ADBCD; Mon, 2 Dec 2013 14:48:10 -0800 (PST)
Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id D5CBE2005D10E; Mon, 2 Dec 2013 14:48:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=BA692yo0NAq9Wt uD1gix/enARew=; b=cCPyL1MoMcr4hMdstm8P2V3SCUvdGHK3AURJNOSm24T0qt 1N4e7WOcg8zOENFRHnu2PLolEjxitn6lASpD01INEB/H2LcVRzbyUDQnlegzHaTm 4RS1J19XE5stVdjPUQ9gMrDtE8zKfxfnlR3M+gs8Jg6ULt48Eo+yw8Ss1vNlI=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPA id 150B42005D10C; Mon, 2 Dec 2013 14:48:07 -0800 (PST)
Date: Mon, 02 Dec 2013 16:48:06 -0600
From: Nico Williams <nico@cryptonector.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Message-ID: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAMm+Lwh-VNdtTRj6=keGMWbANDqQKbj6CODtwe1rquU8H7+32w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
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: Mon, 02 Dec 2013 22:48:12 -0000

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.

Context will affect how much of the schema you or I will find desirable
to see appear redundantly on the wire.  But mostly I agree with you:
"datetime" and such are interpretations of more basic datatypes, and so
they belong in pre-agreed/documented schema rather than on the wire.
Indeed, datetime/timestamp could be either strings or numeric, and still
be understood correctly in context.

> There are many data encodings on offer but I would like to be able to write
> one decoder that can consume a data stream that contains basic JSON data
> and JSON with extensions. This makes negotiating an encoding in a Web
> service easy, the consumer states which encodings are acceptable and the
> sender makes sure what is sent is compatible, downgrading the encoding to
> the level accepted if necessary.

Yes.  Though, really, the main thing that's missing is chunked
(indefinite-length) unescaped binary data.  That's the thing that's
difficult/expenside to deal with in JSON (or XML, for that matter).
Bulk data transfers do matter.  (And if one is going to add that to any
serialization, then plain binary-coded integers and IEEE754 doubles may
be much better, perf-wise, than decimal encodings.)

Nico
--