- From: Tim Berners-Lee <timbl@w3.org>
- Date: Wed, 27 Nov 2013 23:51:29 -0500
- To: Tim Bray <tbray@textuality.com>
- Cc: Alex Russell <slightlyoff@google.com>, "Matt Miller (mamille2)" <mamille2@cisco.com>, JSON WG <json@ietf.org>, IETF Discussion <ietf@ietf.org>, "www-tag@w3.org" <www-tag@w3.org>, es-discuss <es-discuss@mozilla.org>
- Message-Id: <6C28E0DD-5E45-42DB-A915-795EE0A489CC@w3.org>
On 2013-11 -27, at 23:00, Tim Bray wrote: > 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 > JSON is interesting in being a subset of ECMAscript. That is a big dependency -- will it be preserved? However as it is unwise to feed JSON into an ECMAscript processor for security reasons, that dependency may not affect code, just mean that JSON and ECMAscript parsers can share parts at the moment. One could imagine that the arc of ECMAscript's evolution could end up having all kinds of impact on the data structure syntax and semantics. (unordered sets as alternative to lists? who knows). So in that case one could imagine pressure to make a new version of JSON to match. Yes, literal ISO dates and dateTimes -- I added them to my own N3/turtle parsers without much fanfare, wish they had been put in the Turtle language too. Maybe they will. -timbl > On Wed, Nov 27, 2013 at 5:00 PM, Alex Russell <slightlyoff@google.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@textuality.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@cisco.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@ietf.org > https://www.ietf.org/mailman/listinfo/json > > > >
Received on Thursday, 28 November 2013 04:51:37 UTC