I listed some arguments against this in
http://lists.w3.org/Archives/Public/www-tag/2013Oct/0041.html and at the
moment I still believe them. Is there new information?
On top of that, I have no fear of anyone trying to change JSON in the
future; they would be resoundingly ignored by the community of
implementers. I speak as one who would love to add built-in date/time
literals but know that it won’t happen. -T
On Wed, Nov 27, 2013 at 5:00 PM, Alex Russell
<slightlyoff(_at_)google(_dot_)com>wrote:
Will you also be citing ECMA-404 normatively to avoid this sort of
divergence in the future?
On Wed, Nov 27, 2013 at 4:13 PM, Tim Bray <tbray(_at_)textuality(_dot_)com>
wrote:
To do this, I think the draft requires these changes:
- Remove the trailing section of section 1.2, starting with “ECMAscript
5.1 enumerates...” [because the difference no longer exists]
- In section 2:
-- remove “A JSON text is a serialized object or array.”
-- Insert: “A JSON text is a serialized value. Note that certain
previous specifications of JSON constrained a JSON text to be an object or
an array. Implementations which generate only objects or arrays where a
JSON text is called for will be interoperable in the sense that all
implementations will accept these as conforming JSON texts.”
-- Change the JSON-text production to read:
JSON-text = value
On Fri, Nov 22, 2013 at 10:21 AM, Matt Miller (mamille2) <
mamille2(_at_)cisco(_dot_)com> wrote:
There appears to be consensus to change JSON-text to allow for any JSON
value -- not just object / array -- while noting that object or array as
the top-level is the most interoperable.
We will ask the Document Editor to make this change to
draft-ietf-json-rfc4627bis.
- Paul Hoffman and Matt Miller
_______________________________________________
json mailing list
json(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/json