[Json] I-JSON vs. JSON-S

Carsten Bormann <cabo@tzi.org> Mon, 08 July 2013 12:17 UTC

Return-Path: <cabo@tzi.org>
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 4DE7921F9EE1 for <json@ietfa.amsl.com>; Mon, 8 Jul 2013 05:17:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.163
X-Spam-Level:
X-Spam-Status: No, score=-106.163 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 XKRjSE9uD1Z2 for <json@ietfa.amsl.com>; Mon, 8 Jul 2013 05:17:15 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 33AE721F89EB for <json@ietf.org>; Mon, 8 Jul 2013 05:17:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r68CHClX026114 for <json@ietf.org>; Mon, 8 Jul 2013 14:17:12 +0200 (CEST)
Received: from [192.168.217.105] (p54894869.dip0.t-ipconnect.de [84.137.72.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 023A43A73; Mon, 8 Jul 2013 14:17:11 +0200 (CEST)
From: Carsten Bormann <cabo@tzi.org>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 08 Jul 2013 14:17:10 +0200
To: "json@ietf.org WG" <json@ietf.org>
Message-Id: <9326419D-73C0-4098-91F0-0E83A7FEA67A@tzi.org>
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
X-Mailer: Apple Mail (2.1508)
Subject: [Json] I-JSON vs. JSON-S
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: Mon, 08 Jul 2013 12:17:21 -0000

We'll have to bite the bullet at some point and acknowledge there
there are two levels of interoperability in the JSON ecosystem: I-JSON
and JSON-S.

I-JSON is the syntax adapted from JavaScript plus the data model.
Maps are maps, and strings are (Unicode character) strings.  I-JSON is
highly interoperable between different JSON implementations.  (I-JSON
stands for "interoperable JSON" or Tim Bray's "Internet JSON".)

JSON-S is just the syntax.  The data model being used may be related
to that of JSON, but ultimately is application specific.  So, Solr can
have their repeated keys, the "array of general 16-bit values"
faction can have their unpaired surrogates, etc.

When people talk about "not breaking things", it is just not clear
whether they mean "carry along all usages of JSON-S" or "make sure all
I-JSON implementations stil interoperate flawlessly".  That's why the
current charter may have less of a defined meaning than it appears.
Unless the two levels of interoperability are clearly identified, it
is not possible to break neither.

Grüße, Carsten