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

"Pete Cordell" <> Wed, 19 February 2014 17:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DD3591A04FF for <>; Wed, 19 Feb 2014 09:49:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.437
X-Spam-Level: *
X-Spam-Status: No, score=1.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_27=0.6, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id umEe-NgOoyZY for <>; Wed, 19 Feb 2014 09:49:24 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 222D71A03CE for <>; Wed, 19 Feb 2014 09:49:23 -0800 (PST)
Received: (qmail 22681 invoked from network); 19 Feb 2014 17:48:39 +0000
Received: from (HELO codalogic) ( by with ESMTPSA (RC4-MD5 encrypted, authenticated); 19 Feb 2014 17:48:37 +0000
Message-ID: <5E152E5A0BE944F09ED6F96884E3D7F9@codalogic>
From: "Pete Cordell" <>
To: "Tim Bray" <>, "Nico Williams" <>
References: <> <> <> <> <>
X-Unsent: 1
X-Vipre-Scanned: 01B182F100680C01B1843E
Date: Wed, 19 Feb 2014 17:49:24 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original
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
Cc: Phillip Hallam-Baker <>, Paul Hoffman <>, JSON WG <>
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: Wed, 19 Feb 2014 17:49:27 -0000

If the IETF does choose to promote JSON schemas I recommend that such 
languages be designed with the knowledge that their principle use is likely 
to be in RFCs (or similar) documents.  Hence they need to be able to be 
interleaved in with narrative text without limiting the structure of the 
text.  This can be achieved in ways similar to how PHP is included in HTML. 
For example you could do something like:

------------Example start--------------------

2.3.2 Connection Address Type
The ConnectionAddressType represents an IP address and port part that can be 
used to create an IP connection.


ConnectionAddressType ::= object {
    IP4Address address;
    IPPort port;
    String { UDP / TCP / ... } protocol;

- address specifies the IP4 address of the connection.
- port specifies the 16-bit port of the connection
- protocol specifies whether the connection should be made over UDP or TCP.
------------Example end---------------------

This fixes the problem of having narrative and protocol description 
separated by a long way.

Pete Cordell
Codalogic Ltd
C++ tools for C++ programmers,
Read & write XML in C++,
----- Original Message ----- 
From: "Tim Bray" <>
To: "Nico Williams" <>
Cc: "Phillip Hallam-Baker" <>om>; "Paul Hoffman" 
<>rg>; "JSON WG" <>
Sent: Wednesday, February 19, 2014 5:30 PM
Subject: Re: [Json] Nudging the English-language vs. formalisms discussion 

> On Wed, Feb 19, 2014 at 9:20 AM, Nico Williams 
> <>wrote;wrote:
> My proposal is that the WG take all comers for JSON schema languages
>> as Informational and leave it at that (well, all proposals for which
>> there's enough authors and reviewers, enough interest).  That can't
>> even be an irritant for you: you can ignore them...
> No harm in that, although I also perceive little benefit.
>> ...unless you think that formal languages used by others will impair
>> your ability to understand their specs, unless you really prefer
>> English prose to the max.  That'd be an argument I'd want to hear, if
>> you were making it.
> I think schemas can be useful (but designing good schema languages is
> horribly hard, and so easy to get wrong).
> I think clear English prose is *essential*, the one thing a specification
> must have. Thus, schemas can be actively harmful if arguing over them
> distracts attention from crafting the prose properly.  This is 
> particularly
> the case when the schema language is a flawed tool, which so many of them
> are.
> I also think that for most protocols, an open-source validator is 
> immensely
> more useful than a schema. Validators can check semantic constraints that
> are in principle inaccessible to schema languages, especially simple ones.


> _______________________________________________
> json mailing list