Re: [Json] How to argue about I-JSON

Phillip Hallam-Baker <hallam@gmail.com> Mon, 28 April 2014 18:53 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 9A2EB1A700A for <json@ietfa.amsl.com>; Mon, 28 Apr 2014 11:53:21 -0700 (PDT)
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 cVoo_7GG8Qpu for <json@ietfa.amsl.com>; Mon, 28 Apr 2014 11:53:18 -0700 (PDT)
Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) by ietfa.amsl.com (Postfix) with ESMTP id 4FABF1A6FF4 for <json@ietf.org>; Mon, 28 Apr 2014 11:53:16 -0700 (PDT)
Received: by mail-lb0-f181.google.com with SMTP id z11so4029457lbi.40 for <json@ietf.org>; Mon, 28 Apr 2014 11:53:15 -0700 (PDT)
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:content-transfer-encoding; bh=dFIpUUcjq3yAgJP4TmzdkVY7hQhb6r5OOUEqxFgc8Jc=; b=b68L2f0S+H7Mr0AF0YRAWB4l9Bg5Q1y6aXilX5AdJ40r+N05xxELrIk0gpk5H0HdYf Vg7amQO5CJxCFHbBl242Hk33YCkGw6MkDpkvpK9wCZzxJNzRL4S/+8eel26AtAEWmtFG z2Tx9dMjtC8PlygGhf7H1zbo/ly1YDTG9RSUh655NcT7qlBY8G52kesVzqdF7p1PPZDc JCaHu51XFCihmOZ1Q0sVKLAIzmERk6uJ+aG9WhVowyqUcFZtP/mZsf8+hX4cIE8colnq tqoAqFUZoFa18wviw9X2RvT4rcMCIlyTsG4h/O/g0aAj24vGKryMCAQkilVTeYtv60dd R+tA==
MIME-Version: 1.0
X-Received: by 10.152.203.168 with SMTP id kr8mr2482130lac.17.1398711194836; Mon, 28 Apr 2014 11:53:14 -0700 (PDT)
Received: by 10.112.234.229 with HTTP; Mon, 28 Apr 2014 11:53:14 -0700 (PDT)
In-Reply-To: <CAHBU6iurWB29LujFibWBgcLMsH-n0Jkide_8gAR8fs_FEvoMRA@mail.gmail.com>
References: <CAHBU6iurWB29LujFibWBgcLMsH-n0Jkide_8gAR8fs_FEvoMRA@mail.gmail.com>
Date: Mon, 28 Apr 2014 14:53:14 -0400
Message-ID: <CAMm+LwjUxJztHsd=iPw=p4NBx8EaosCXMjHVNSiWvfpEgZOF6A@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Tim Bray <tbray@textuality.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/json/43_yZmPPZrWrmZgRYpfBPp4jpHo
Cc: "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] How to argue about I-JSON
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, 28 Apr 2014 18:53:21 -0000

On Mon, Apr 28, 2014 at 2:16 PM, Tim Bray <tbray@textuality.com> wrote:
> This is an attempt to leap in front of the debate, use the take-aways from
> the very useful London f2f, and make our time arguing about I-JSON maximally
> productive
> .  There are plenty of bikesheds out there, but I think the number of useful
> arguments is limited and the issues in them pretty clear.
>
> Argument 1 - Media types?
>
> Should there be an I-JSON media type, or a application/*+i-json suffix?
> draft i-json-01 calls for it, but this is at best controversial.  My
> suggestion is that people who still think this is a good idea
> need to speak up.  (I won’t.)

No, if there is a different media type from JSON then I won't every use it.


> Argument 2 - Top-level
>
> draft-i-json-01 says the top level is an object (but doesn’t say MUST, eek).
> I have heard arguments for allowing arrays too; anyone who thinks that is a
> good idea should speak up. (I won’t.)

I can see applications where I want multiple top level objects but not
in Web Services protocols. I can't see a reason to exchange more than
one object per transaction slot.

The one case where I can see an argument for having multiples is log
files. And we had a long argument over that a while back, the
alternatives being

A:  [ {entry1} , {entry2}, {entry3} ]
B:  {entry1} , {entry2}, {entry3}
C:  {entry1}  {entry2} {entry3}

The arguments against being:

A: Cannot be written as an append-only operation. The last ] messes
everything up
B: No particular reason against
C: Isn't a proper JSON encoding

A is obviously a non-starter, so taking these arguments, the best choice is C.

The reason for this became obvious when I tried to actually use a log
file with a JSON structure. Because the thing about log files is that
you often want to jump into the middle of the log and look there.

The problem with option B is that there is no way to tell whether a
coma is a separator of two elements within one entry or two entries.
They both look the same. So there is no way to resynchronize.


The only relevance here is that if we don't need option A then I can't
see much purpose in having an array as a toplevel entry.

But what would make sense is to have a MIME type for a JSON log format
which consists of a sequence of JSON objects that are separated by a
(possibly null) sequence of whitespace entries.


> Argument 5 - Numbers
>
> draft-i-json-01 says that you MUST not put in a string representing a number
> with greater precision/magnitude than IEEE754 doubles can support.   I think
> this is a good idea but I'm a little nervous because I’ve never written the
> code, if this is unreasonably hard at either the sending or receiving end
> someone should  say so.

Seems pointless to me. if you care about precision then you don't want
to use decimal encoding for a binary float.

Probably a better restriction would be to say that reals cannot be
more than X characters long so that the encoder/decoder can know when
to abort.

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