Re: [Json] Nudging the English-language vs. formalisms discussion forward

"Pete Cordell" <> Thu, 20 February 2014 13:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5E3291A014F for <>; Thu, 20 Feb 2014 05:02:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.398
X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jYT6w8FaFlQc for <>; Thu, 20 Feb 2014 05:02:45 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id AC5201A0155 for <>; Thu, 20 Feb 2014 05:02:41 -0800 (PST)
Received: (qmail 6067 invoked from network); 20 Feb 2014 13:01:23 +0000
Received: from (HELO codalogic) ( by with ESMTPSA (RC4-MD5 encrypted, authenticated); 20 Feb 2014 13:01:21 +0000
Message-ID: <47BB9131737D42218A6382DEF45BBE2C@codalogic>
From: "Pete Cordell" <>
To: "Cyrus Daboo" <>, "Carsten Bormann" <>, "JSON WG" <>
References: <> <> <> <> <> <> <> <> <> <357740A8AA0F4316BE630917321FAB4D@codalogic> <B1EBE05A69362F001777F807@cyrus.local>
X-Unsent: 1
Date: Thu, 20 Feb 2014 13:01:54 -0000
X-Vipre-Scanned: 00EA2BEF00682600EA2D3C
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
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] Nudging the English-language vs. formalisms discussion forward
X-Mailman-Version: 2.1.15
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: Thu, 20 Feb 2014 13:02:47 -0000

----- Original Message From: "Cyrus Daboo"
> Please take a look at Andrew Newton's spec 
> (<>).

Thanks Cyrus.  It certainly looks like another option.  I would suggest that 
the authors could look at the following to improve it:

- It doesn't seem to have much in the way of supporting modularity.  It 
would be attractive if a schema could pull in and use definitions defined in 
other documents.  Many IETF protocols consist of suites of components and 
support for that would be handy.

- It doesn't seem to support third-party extensions to a core protocol.  For 
example, HTTP and SIP are defined in a core RFC but there are then a number 
of additional RFC that define extensions.  Support for expressing how a new 
extension can extend an existing external extension would be good.  (Just 
about every schema language I've seen fails miserably at this!)

- The plethora of data types are a problem for schema languages.  I've come 
to the conclusion that the best option is to declare a "microformat" 
pseudo-type that basically says this is a string encoded in a particular 
way.  The 'particular way' can then be defined in narrative form as required 
(80-20 etc).  This avoids having to define the kitchen sink of data types up 
front.  e.g.:

struct Asset
    GPSLocation location;

microformat GPSLocation;
    // A GPSLocation is a pair of comma separated floating-point
    // numbers representing longitude and latitude.
    // e.g. "location": "0.0,51.5"

- Does it allow multiple roots to be defined?  Many protocols have 
request/response type pairs so it's nice to define a protocol that has the 

"request": {...} and "response": {...}

Pete Cordell
Codalogic Ltd
C++ tools for C++ programmers,
Read & write XML in C++,
----- Original Message ----- 
From: "Cyrus Daboo" <>
To: "Pete Cordell" <>om>; "Carsten Bormann" 
<>rg>; "JSON WG" <>
Sent: Thursday, February 20, 2014 2:05 AM
Subject: Re: [Json] Nudging the English-language vs. formalisms discussion 

> Hi Pete,
> --On February 19, 2014 at 10:29:32 PM +0000 Pete Cordell 
> <> wrote:
>> I thought I'd throw down n gauntlet as a baseline for something to be
>> beat. So I started with something C like, and stole stuff from other
>> languages and came up with the following
> Please take a look at Andrew Newton's spec 
> (<>).
> I have used that in two specs of my own:
> <>
> <> 
> Appendix B
> I found it to be easy to use and provide the necessary "commentary" for 
> the JSON format chosen for those specs. I know several others who have 
> implemented the timezone service protocol and we had no issues with 
> interoperability related to the JSON format (beyond some poor text 
> descriptions on my part).
> As Andrew noted earlier, his spec could probably be simplified some more - 
> but we certainly don't need anything more complicated than what is there 
> now.
> -- 
> Cyrus Daboo