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

Carsten Bormann <> Wed, 19 February 2014 20:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3C46E1A05CC for <>; Wed, 19 Feb 2014 12:02:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tvjI6AtTPc6g for <>; Wed, 19 Feb 2014 12:02:49 -0800 (PST)
Received: from ( [IPv6:2001:638:708:30c9::12]) by (Postfix) with ESMTP id 689D41A04F7 for <>; Wed, 19 Feb 2014 12:02:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s1JK2i1h028985 for <>; Wed, 19 Feb 2014 21:02:44 +0100 (CET)
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id DF2E1E12; Wed, 19 Feb 2014 21:02:43 +0100 (CET)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Wed, 19 Feb 2014 21:02:42 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: JSON WG <>
X-Mailer: Apple Mail (2.1827)
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 20:02:51 -0000

At the danger of repeating myself and others here, I’ll try to summarize:

— We have quite good experience with using a single, standard (!) ABNF in IETF protocols.
  ABNF is a production system with well-understood semantics.
  It is somewhat idiosyncratic in the world of EBNF, but that has caused *zero* problems in practice.
  (People have just written ABNF parsers.  You still have the second half of the afternoon to do something else after that.)

— A production system that generates JSON (at the data model level) is easy to do.
  (But we have to find people who have the background and can commit the time.)  

— Relax NG compact is a nice existence proof that a production system like this can work and be highly usable.
  A JSON version could be even simpler.

— Previous attempts at trying to express XML or JSON data model syntax in the formalism of XML or JSON itself provide incontrovertible proof that this approach does not work.
  Don’t do that then.
  (It is so much easier to spend half the afternoon writing the parser for the workable syntax.
   We can even spec it in ABNF!)

— If you want to cover 100 % of the “syntax” of an XML document, you need to add Schematron to Relax NG compact.
  a) Don’t do that then for JSON — stay with an 80 % solution like Relax NG (which is more like 90 %) or maybe even simpler.
  b) Choose some form of “Jpath” to complement the production system with assertions.

(Note that choice b can always be added later, on a separate timeline from doing a production system.)

My proposals following from this little exercise in fact finding:

— I would propose that we try to find energy for doing the production system.
(In addition to the Web people, we may want to tap the YANG people for some recent experience in doing this kind of work.)

— I would propose that we stay open to adding a Jpath/Schematron approach (choice “b”), *if* somebody brings a credible one to the table.

— I also would propose that we collect a small number of benchmarks that we use for demonstrating that proposals for the production system are useful.
  My first suggestion: RFC 7071.  But we need a couple of different ones.  RFC 7095?  Maybe too ambitious.

Grüße, Carsten