Re: [Json] Two Documents

I think the current lucid, succinct text that describes a data model, a
language, and a byte serialization is so useful because it comprehensively
describes all three things. So I wouldn't break it up.

The byte serialization description is essential because in order to
actually use JSON for anything you must deal with some byte serialized
form, and in 99% of cases that will be the application/json form.

I advocated dropping the mentions of Unicode except in byte serialization
and character lookup for Unicode escapes. That's as a matter of clarity
since those mentions are extraneous, and also so that applications that
represent models without using Unicode or serialize to non-Unicode
encodings not described as application/json are not needlessly deemed
non-compliant. But I think those changes are relatively unimportant; few
people are going to be confused by the current text, and those who are
doing non-compliant things probably don't know or care.

On Thu, Jun 13, 2013 at 8:50 AM, Douglas Crockford <douglas@crockford.com>wrote:

> The confusion and controversy around this work is due to a mistake that I
> made in RFC 4627. The purpose of the RFC, which is clearly indicated
> in the title, was to establish a MIME type. I also gave a description of
> the JSON Data Interchange Format. My mistake was in conflating the two,
> putting details about the MIME type into the description of the format. My
> intention was to add clarity. That obviously was not the result.
>
> JSON is just a format. It describes a syntax of brackets and commas that
> is useful in many contexts, profiles, and applications. JSON is agnostic
> about all of that stuff. JSON shouldn't even care about character encoding.
> Its only dependence on Unicode in the hex numbers used in the \u notation.
> JSON can be encoded in ASCII or EBCDIC or even Hollerith codes. JSON can
> be used in contexts where there is no character encoding at all, such as
> paper documents and marble monuments.
>
> There are uses of JSON however in which such choices matter, and where
> behavior needs to be attached to or derived from the syntax. That is
> important stuff, and it belongs in different documents. Such documents
> will place necessary restrictions on JSON's potential. No such document
> can fit all applications, which causes much of the controversy we've seen
> here. One size cannot fit all. JSON the format is universal. But real
> applications require reasonable restrictions.
>
> So we should be working on at least two documents, which is something we
> have
> discussed earlier. The first is The JSON Data Interchange Format, which is
> a simple grammar. The second is a best practices document, which recommends
> specific conventions of usage.
>
> ______________________________**_________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/**listinfo/json<https://www.ietf.org/mailman/listinfo/json>
>