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

Phillip Hallam-Baker <> Tue, 18 February 2014 00:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C37441A0422 for <>; Mon, 17 Feb 2014 16:59:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aXQn5vu_Y38F for <>; Mon, 17 Feb 2014 16:59:12 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::22c]) by (Postfix) with ESMTP id EF1DE1A02BD for <>; Mon, 17 Feb 2014 16:59:11 -0800 (PST)
Received: by with SMTP id c11so11923644lbj.3 for <>; Mon, 17 Feb 2014 16:59:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tJsQqvHQJlHr/cEAaUhuJFawmBEHFDeUrDgmnOzF2Bk=; b=KpIYtvTGURnEMy5H6M3mlNny/rVeRAYm42lvL+uF/LSpJ4+LpTkeOFXc2BJHIXO8Jt AZuFMkhyWr7pRaUeY2wetu8lJb7D0/MkxPmmm4+yUDyd4+teEnIW6I6y7hWnmmvsRmbG WpfjXD3itJq5ckDSDlQy4pqTbqDM+YNKY4kPgksB4mfSkipkFqRFor9JZMCYcoHLvOXt bqestJ/6UJeSUVzAeM/+GpRkL+Ro/Ipg4YAG5r5RVqXB6YUGcvWGqP+G8/DSLjTLhKE0 +YkRsrRFosNWfGoY2W/C6Ojg1Y0zBCYLhsmEo0Jp1lAFw04SK9/NBiyqU2/FnD+LYuUv snzQ==
MIME-Version: 1.0
X-Received: by with SMTP id s8mr24379las.55.1392685148382; Mon, 17 Feb 2014 16:59:08 -0800 (PST)
Received: by with HTTP; Mon, 17 Feb 2014 16:59:08 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Mon, 17 Feb 2014 19:59:08 -0500
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Paul Hoffman <>
Content-Type: multipart/alternative; boundary="047d7b8743a48dab2304f2a3c74f"
Cc: 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: Tue, 18 Feb 2014 00:59:15 -0000

On Mon, Feb 17, 2014 at 7:23 PM, Paul Hoffman <> wrote:

> It's been a week, and yet I can't imagine that everything has been said
> with respect to our proposed charter item that now stands at:
>    A set of natural-language terms and/or phrases for use in future
> specifications
>    that use JSON. This explicitly excludes schema languages and similar
> formalisms.
> After that, a bunch of people started talking about formalisms and actual
> schemas again. In order to get this decided, we need more discussion and
> then agreement. To that end, and to put our 90 minutes on Friday afternoon
> in London to best use, I will ask for at least three people to present
> their views in 10-minute presentations at the meeting. However, in order to
> cause this to not be the normal IETF "let's wait for the meeting" game, the
> presentations need to be done by next Monday, Feb. 24. That gives people on
> the list a preview of what will be said, time to argue about it, and time
> for the presenters to hone their slides if they want.
> Let me know online or offline if you want to do a presentation. If you're
> not going to be at the meeting but want to say something, you need to find
> some like-minded soul with whom to work on the presentation.

I have a tool that I would like to present.

The input to the tool is an abstract description of a data structure, the
output is code that generates JSON serializer and deserializer code from
the description and xml2rfc or html text that describes the interpretation
of the data structure.

All the code and reference material in the following document were
generated with the tool

The advantage of working this way is that if a change is made to the
specification it will automatically make its way into the examples and the
reference material. So if someone decides that the tag should be "DateTime"
rather than "Date" you can edit one field in one file and be confident that
the changes are reflected through all the examples. No more hunting through
the examples to make sure that all the changes were made consistently.

The code is on SourceForge and an update I am working on provides code in C
as well as C#.

The abstract description is not in JSON. This is deliberate, I find JSON to
be rather noisy as a text entry format. Plus you might face what we saw in
the KEYPROV working group where the core spec was in one format (XML) but
another group of people wanted to do ASN.1 because thats what the rest of
crypto is done in. It would be very easy to dump out ASN.1 and XML schemas
from the same tool. All that is required is a new output script to generate
the other schema language.

I do however have a flight out of LHR at 16:00 so I have constraints..