Re: [Json] 2-step proposal 4627bis + I-JSON

"Manger, James H" <James.H.Manger@team.telstra.com> Thu, 04 July 2013 01:36 UTC

Return-Path: <James.H.Manger@team.telstra.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B36211E80F1 for <json@ietfa.amsl.com>; Wed, 3 Jul 2013 18:36:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level:
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6blODYY1ppPw for <json@ietfa.amsl.com>; Wed, 3 Jul 2013 18:36:23 -0700 (PDT)
Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 59AAF11E80D9 for <json@ietf.org>; Wed, 3 Jul 2013 18:36:22 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.87,992,1363093200"; d="scan'208";a="144839365"
Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipobvi.tcif.telstra.com.au with ESMTP; 04 Jul 2013 11:36:21 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,7125"; a="142140250"
Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipccvi.tcif.telstra.com.au with ESMTP; 04 Jul 2013 11:36:21 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Thu, 4 Jul 2013 11:36:20 +1000
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: Tim Bray <tbray@textuality.com>, "json@ietf.org" <json@ietf.org>
Date: Thu, 4 Jul 2013 11:36:19 +1000
Thread-Topic: [Json] 2-step proposal 4627bis + I-JSON
Thread-Index: Ac54R4cHyJQecUt+Q2SV2qHKTB/X3gAAMTbw
Message-ID: <255B9BB34FB7D647A506DC292726F6E1151C19AD73@WSMSG3153V.srv.dir.telstra.com>
References: <CAHBU6itqGgndUKRUHH_q6fv8jonGL3VVHhkezFne0sC3T12c_Q@mail.gmail.com>
In-Reply-To: <CAHBU6itqGgndUKRUHH_q6fv8jonGL3VVHhkezFne0sC3T12c_Q@mail.gmail.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [Json] 2-step proposal 4627bis + I-JSON
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 04 Jul 2013 01:36:28 -0000

> 2. Recharter in a way that will allow us to produce something like a
> strawman I cooked up, I-JSON: https://www.tbray.org/tmp/i-json.html
> Produce something like that. Second victory!
>  -T

I-JSON has some great sections, but..

"urn:ietf:i-json":true  -- Ugh? Why? How do you think this would be used by apps receiving JSON? Do they switch between rejecting dups vs accepting last dup based on the presence of this element? Sounds unlikely.

"which MUST be the first member of the top-level object" -- please don't have this. It violates the rule that object elements are *unordered*, which just encourages more such violations.


We could claim victory if this spec encouraged most "common" JSON parsers to be modified so they could say they are I-JSON-compliant. That requires "common" parsers to switch to throwing an error when a dup is detected, instead of silently accepting the last value. I would love to see that, but I have seen no sign that this is likely.
 
--
James Manger