Re: [Json] Two Documents

["Joe Hildebrand (jhildebr)" <[e-mail]>]

I agree with Tim.  I think we can make it crystal clear with wording and
structural changes at what point a person that already has a stream of
codepoints (rather than a stream of octets) starts implementing.

Of course, I want to make sure we don't *prohibit* more performant
processors that both decode and parse in one pass, but that won't work for
JSON.parse unless ECMA allows JSON.parse to also take a typed array in
addition to a string or adds JSON.parseBuffer.


On 6/19/13 8:33 AM, "Tim Bray" <[e-mail]> wrote:

>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
><[e-mail]> 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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/json
>
>
>
>
>
>
>
>


-- 
Joe Hildebrand