Re: [Json] Two Documents

Douglas Crockford <douglas@crockford.com> Wed, 19 June 2013 02:07 UTC

Message-ID: <51C1121E.8050004@crockford.com>
Date: Tue, 18 Jun 2013 19:06:22 -0700
From: Douglas Crockford <douglas@crockford.com>
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: "Matt Miller (mamille2)" <mamille2@cisco.com>
References: <51B9EA49.2050604@crockford.com> <BF7E36B9C495A6468E8EC573603ED9411528A0E2@xmb-aln-x11.cisco.com>
In-Reply-To: <BF7E36B9C495A6468E8EC573603ED9411528A0E2@xmb-aln-x11.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Two Documents
Precedence: list

On 6/17/2013 5:14 PM, Matt Miller (mamille2) wrote:
> Hello Douglas,
>
> In order for the WG to fully understand your proposal, we need a more definitive list of what to expect in each document.
>
> As a starting point, can you describe which sections of the current RFC4627 would be in "JSON Data Interchange Format" and which would be in the JSON best practices document?  Clearly the latter will have many additions from the recent discussions, but it is less clear which portions of the current text goes into which document.
>
Please excuse the lateness of this reply. I am traveling.

I am proposing that The JSON Data Interchange Format document contain 
only the material that is universal to all applications of JSON. So, for 
example, the only dependency on any character encoding is the 
interpretation of the four hex digits in the \u notation, where Unicode 
determines the meaning of the numbers.

It includes an abstract, an introduction, the detailing of the elements 
(object, array, string, etc), and security considerations. No parsers or 
generators, no octets, no MIME types.

This provides a standard description of JSON that all other standards 
and practices may refer to. I think this is the standard that ECMA wants 
to publish.

We can then consider other documents that constrain or interpret JSON 
for specific purposes. The poorly named application/json is one. JSON as 
a file format, JSON as a streaming format, and JSON as an embedded data 
representation are others.

[Json] Two Documents Douglas Crockford
Re: [Json] Two Documents John Cowan
Re: [Json] Two Documents Douglas Crockford
Re: [Json] Two Documents Mark Miller
Re: [Json] Two Documents Markus Lanthaler
Re: [Json] Two Documents Tim Bray
Re: [Json] Two Documents Carsten Bormann
Re: [Json] Two Documents Nico Williams
Re: [Json] Two Documents John Cowan
Re: [Json] Two Documents Jacob Davies
Re: [Json] Two Documents R S
Re: [Json] Two Documents Tim Bray
Re: [Json] Two Documents Eliot Lear
Re: [Json] Two Documents Matt Miller (mamille2)
Re: [Json] Two Documents Vinny A
Re: [Json] Two Documents Paul Hoffman
Re: [Json] Two Documents Douglas Crockford
[Json] On representing what ECMA wants Paul Hoffman
Re: [Json] Two Documents Paul Hoffman
Re: [Json] On representing what ECMA wants Rick Waldron
Re: [Json] On representing what ECMA wants Mark Miller
Re: [Json] On representing what ECMA wants Paul Hoffman
Re: [Json] Two Documents Markus Lanthaler
Re: [Json] Two Documents Stefan Drees
Re: [Json] Two Documents Tim Bray
Re: [Json] Two Documents Carsten Bormann
Re: [Json] Two Documents Joe Hildebrand (jhildebr)
Re: [Json] Two Documents John Cowan
Re: [Json] Two Documents Nico Williams
Re: [Json] Two Documents Pete Cordell
Re: [Json] Two Documents Carsten Bormann