[Json] "best practices" Vs. Profile for i-json

Larry Masinter <masinter@adobe.com> Fri, 01 August 2014 21:56 UTC

Return-Path: <masinter@adobe.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 4ADE41A00DF for <json@ietfa.amsl.com>; Fri, 1 Aug 2014 14:56:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 l0v74vnImxGL for <json@ietfa.amsl.com>; Fri, 1 Aug 2014 14:56:02 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D16931A0084 for <json@ietf.org>; Fri, 1 Aug 2014 14:56:01 -0700 (PDT)
Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB305.namprd02.prod.outlook.com (10.141.91.17) with Microsoft SMTP Server (TLS) id 15.0.995.14; Fri, 1 Aug 2014 21:55:54 +0000
Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0995.014; Fri, 1 Aug 2014 21:55:54 +0000
From: Larry Masinter <masinter@adobe.com>
To: IETF JSON WG <json@ietf.org>
Thread-Topic: "best practices" Vs. Profile for i-json
Thread-Index: Ac+t0SKL9u+Yq7ZcQd6oHwhjU/yjwA==
Date: Fri, 01 Aug 2014 21:55:54 +0000
Message-ID: <2d53157574f749e0b1399b9e39564ecd@BL2PR02MB307.namprd02.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [50.184.24.49]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 029097202E
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(99286002)(19580395003)(87936001)(74662001)(92566001)(20776003)(64706001)(21056001)(79102001)(66066001)(76482001)(46102001)(105586002)(80022001)(83322001)(85306004)(2656002)(95666004)(15202345003)(77982001)(107046002)(74502001)(81542001)(107886001)(33646002)(101416001)(4396001)(81342001)(83072002)(229853001)(85852003)(76576001)(74316001)(31966008)(50986999)(86362001)(99396002)(54356999)(106356001)(15975445006)(110136001)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB305; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
Archived-At: http://mailarchive.ietf.org/arch/msg/json/wlLKy9Sb3GJtsxGuPxsIwENM9Hw
Subject: [Json] "best practices" Vs. Profile for 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: Fri, 01 Aug 2014 21:56:04 -0000

My conclusion after some discussions at IETF is that i-json needs to separate "best practices" vs "profile".

The SHOULD belongs with best practices: e.g., "numbers in I-JSON SHOULD be representable by IEEE floating point."

If you want a real profile, though, you need clear criteria:
"All numeric values in I-JSON MUST round-trip to IEEE floating point and back to the same string." 
And then if you want an exception, make it application dependent: "the result must be JSON and SHOULD be I-JSON".

But the current doc mixes these together in a way that makes it less useful.

If you don't want both, just do the profile.  

Related topic: consider I-JSON a kind of normalization to an idealized JSON data model. Make the data model explicit.
Insure round-trip between data model and i-json is not information lossy.
Then any operation which defines itself in terms of the data model and not the textual representation would automatically get i-json output, such as Merge/patch and schemas.


Larry
--
http://larry.masinter.net