Re: [Json] Two Documents

Let’s take a moment to consider who our audience is.  The RFC will be used
almost exclusively by JSON parser and generator implementors. Out in the
general population of JSON users, the only docs they look at are the docs
for the parser/generator library they’re using.

And if I’m an implementor writing a JSON parser or generator, well, yeah, I
care about the abstract grammar and the security issues, but I also care
about what the incoming sequence of bytes is going to look like, and what
the outgoing sequence of bytes needs to look like.

So I think it would be abusive to our customers to make them read two
documents to get their jobs done.  I’m scratching my head to think of
anyone who would read one of these documents but not the other, and I’m
coming up empty.

 -Tim

On Tue, Jun 18, 2013 at 7:06 PM, Douglas Crockford <douglas@crockford.com>wrote:

> 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 mailing list
> json@ietf.org
> https://www.ietf.org/mailman/**listinfo/json<https://www.ietf.org/mailman/listinfo/json>
>