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

Phillip Hallam-Baker <hallam@gmail.com> Wed, 19 February 2014 22:28 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3191A025C for <json@ietfa.amsl.com>; Wed, 19 Feb 2014 14:28:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKGQmbdvqrbE for <json@ietfa.amsl.com>; Wed, 19 Feb 2014 14:28:21 -0800 (PST)
Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id 961011A0226 for <json@ietf.org>; Wed, 19 Feb 2014 14:28:20 -0800 (PST)
Received: by mail-lb0-f169.google.com with SMTP id q8so784599lbi.0 for <json@ietf.org>; Wed, 19 Feb 2014 14:28:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WBkYow+FcKosRECdfMFy+lY1EI1BfKyflycRkK2kwMM=; b=pzGcFm/r6UqS/7LmX4T8nt4dLbBrQVfi2Eht7W+X5nRkLUZsCH4g9OlH1EcYvRsCWk WxB3A0JUgpDEJyfR0G6+MyPhWrIeCdIjihcqgEgGHDX2bfLluoo3LXEKMd2CxtHUcVax pdNWSnyaqR6AaCeMRZuU7BM5Eh21IvGZ5iua2lciq7UALFDYbliAF3YTMXtEep0uHXNW Q6NDMO9atsrQeyRzbSsOkwBoPieVUSzTQNU7Lqj6hj3PghHWBM5EcBk10yFdOLkM1Y4H YuxTorCCuo7Ra2XE4OcgxfLRUA+qq19SeAHCEIjDweRY//+awfNSaO60LMAE8Kg0pGV0 bP3Q==
MIME-Version: 1.0
X-Received: by 10.112.72.40 with SMTP id a8mr2344418lbv.68.1392848896514; Wed, 19 Feb 2014 14:28:16 -0800 (PST)
Received: by 10.112.37.168 with HTTP; Wed, 19 Feb 2014 14:28:16 -0800 (PST)
In-Reply-To: <CAC4RtVDLQ3q5KxG+jDYfDB09JZUOBcojTR3ebxhr1QUOXLeEvA@mail.gmail.com>
References: <C87F9B96-E028-4F0E-A950-B39D3F68FFE7@vpnc.org> <CAMm+LwhUh_yN-hzaoDWfrO_H2iGvYvj99BCE4EcYmgqCPqXoVQ@mail.gmail.com> <CAHBU6itpttXBfVQGKw=u==k_XSdrht81+m_YDNZP6RM+=9CNow@mail.gmail.com> <CAK3OfOjHkBFOzJSx=bhhoQJ8Z2bWyEXK52dNyYGWVb9FAj99ow@mail.gmail.com> <CAHBU6itzQ0rzU3EUYUqzm2qhx03qk1mpx2sehS_zeiw1ypcEgw@mail.gmail.com> <CAK3OfOhfjkbq6eREkt=MBVL1C9ubh-6My3Lvg-mnOxD0+cpN1Q@mail.gmail.com> <CAHBU6isZbew8O1HJ+XcFsMCR42iDoO_uemPXVwa3=vM5A=MngA@mail.gmail.com> <CAK3OfOgmVsNJqrqCfsD7h37axssOoaX3DGHqO=bTn5bWrA+MFA@mail.gmail.com> <A4B53816-6FBF-4A37-8BC9-F0A9D0867BCD@tzi.org> <CAC4RtVDLQ3q5KxG+jDYfDB09JZUOBcojTR3ebxhr1QUOXLeEvA@mail.gmail.com>
Date: Wed, 19 Feb 2014 17:28:16 -0500
Message-ID: <CAMm+LwiCHt2NLW8AV93Tzh=hUXGT7SWM8W5zXSehmBF+nEMCkw@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Barry Leiba <barryleiba@computer.org>
Content-Type: multipart/alternative; boundary="001a11c23e2eb3e24404f2c9e795"
Archived-At: http://mailarchive.ietf.org/arch/msg/json/OXEvLkaafSX4rbpVQ_wxozc-nAA
Cc: JSON WG <json@ietf.org>
Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Feb 2014 22:28:23 -0000

On Wed, Feb 19, 2014 at 5:04 PM, Barry Leiba <barryleiba@computer.org>wrote:

> Using Carsten's "summary" note as an anchor, let me back up to where
> this proposal came from.
>
> I'm interested in providing a recommended way (through a non-binding,
> Informational document that describes it) in which protocol elements
> that are JSON things can be described in documents.  I'm hoping we can
> keep this work item to that limited scope, and not go too far in
> trying to devise something mega-general that does everything but
> eat.[1]
>
> That means that I'm looking for something that addresses the 90% case
> nicely and cleanly.  The 10% of the messier cases should be workable,
> but can be messier, I think.  As an example of what made me think
> about this, look at these:
> 1. Section 6.1.1 of
> http://tools.ietf.org/html/draft-ietf-repute-media-type-12
> 2. Section 6.2.2 of
> http://tools.ietf.org/html/draft-ietf-repute-media-type-13
>
> Note that the attempt to reproduce the JSON ABNF, in version -12, had
> a number of problems.  I think the mechanism in version -13 is much
> cleaner... and it's simple and easy to explain.  Nested and complex
> structures can be handled as they are in ABNF, by naming the nested or
> complex bit and then expanding it in another "rule".  I think this
> sort of mechanism meets the "addresses the 90% case nicely" desire.  I
> like it because it's easy to write and, more importantly, easy to read
> and understand.
>

It is obviously possible to create an ABNF description of JSON (call this X)

It is thus possible to create an ABNF description of a Web Service message
as an ABNF description. (Call this Y)


What I think is going to be very hard is proving that a given Y is a subset
of X. And if we do that we risk having specifications that are not actually
JSON but only JSON-like.

Unless that is we start off with a tool that generates Y in a fashion that
makes it easy to check that it is a subset of X.

-- 
Website: http://hallambaker.com/