Re: [Json] Two Documents

"Pete Cordell" <> Wed, 19 June 2013 15:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 63E8221F9CC9 for <>; Wed, 19 Jun 2013 08:37:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.743
X-Spam-Level: *
X-Spam-Status: No, score=1.743 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_50=0.001, SARE_HEAD_XUNSENT=1.666, STOX_REPLY_TYPE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id grRBw6ZgHY7I for <>; Wed, 19 Jun 2013 08:37:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EBA5121F9CE7 for <>; Wed, 19 Jun 2013 08:36:58 -0700 (PDT)
Received: (qmail 19860 invoked from network); 19 Jun 2013 16:36:57 +0100
Received: from (HELO codalogic) ( by with (RC4-MD5 encrypted) SMTP; 19 Jun 2013 16:36:57 +0100
Message-ID: <2E8AF23771284CF0BE394DBFF12DEB80@codalogic>
From: "Pete Cordell" <>
To: "Tim Bray" <>
X-Unsent: 1
References: <><><> <>
x-vipre-scanned: 01A7FB000049A801A7FC4D
Date: Wed, 19 Jun 2013 16:37:03 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Subject: Re: [Json] Two Documents
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Jun 2013 15:37:06 -0000

Original Message From: "Tim Bray"

> So I think it would be abusive to our customers to make them read two
> documents to get their jobs done.  I’m scratching my head to think of
> anyone who would read one of these documents but not the other, and I’m
> coming up empty.

My feeling is that the current JSON spec has warts, largely due to 
ambiguity, that many of us would like to see resolved, but by the nature of 
backwards compatibility we can't fix them with a one document strategy.

I'm musing that what I'd ideally like to see is a document to describe JSON 
as it currently is, warts and all, in a document called "The JSON Data 
Interchange Format".  As much as anything this would highlight ambiguities 
in the current spec, but not necessarily resolve them.

Then have a separate spec named along the lines of "The Good JSON Data 
Interchange Format" that has a structure similar to the first, but has 
wording along the lines of "A good JSON parser MUST..." etc.

Hopefully the second one can be effectively JSONbis and a single document 
source for anybody that wants to go that route, and is also less ignorable 
than an informational BCP for those that like to cut corners on 

Pete Cordell
Codalogic Ltd
C++ tools for C++ programmers,
Read & write XML in C++,