W3C home > Mailing lists > Public > www-tag@w3.org > December 2013

Re: [Json] Consensus on JSON-text (WAS: JSON: remove gap between Ecma-404 and IETF draft)

From: Alex Russell <slightlyoff@google.com>
Date: Mon, 2 Dec 2013 17:26:17 -0800
Message-ID: <CANr5HFXS3jc+E_q7yrNO7abhh+Qoxz5a6kuTog12Gg=bV-W6tA@mail.gmail.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Cc: Tim Berners-Lee <timbl@w3.org>, Tim Bray <tbray@textuality.com>, IETF Discussion <ietf@ietf.org>, JSON WG <json@ietf.org>, "Matt Miller (mamille2)" <mamille2@cisco.com>, "www-tag@w3.org" <www-tag@w3.org>, es-discuss <es-discuss@mozilla.org>
On Mon, Dec 2, 2013 at 1:30 PM, Phillip Hallam-Baker <hallam@gmail.com>wrote:

> On Wed, Nov 27, 2013 at 11:51 PM, Tim Berners-Lee <timbl@w3.org> wrote:
> 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.
> As I see it, encoding X is a subset of encoding Y if and only if an
> encoder for X will only produce outputs that are valid inputs of encoding Y.
> If an issue was to occur it would be because encoding Y has changed or the
> definition of Y has changed.
> 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.
> Since we are talking about a serialization format, the distinction between
> unordered sets and lists cannot occur at the wire level and this is where
> we need interoperation.
> I do in fact have a schema compiler for JSON that allows an interface to
> specify a set of entries rather than a list. But they are only ever
> serialized as lists.
> 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.
> And you probably do exactly what I do and represent a DateTime
> representation as a subset of String just as byte, int16, int32, int64,
> uint* are all subsets of Integer.
> One of the things I think we have learned from JSON is that a
> self-describing format only needs to specify the abstract type of the datum
> and not the representation.
> For convenience, I allow a schema to specify the size of an integer and
> whether it is signed or unsigned so that the code generator can create
> appropriate code bindings. But none of that shows up on the wire, nor is
> that particularly helpful.
> What we are doing at this point is to fix a version of the JSON encoding
> in time so that when a client and server are negotiating use of JSON
> encoding, both sides know what is being negotiated.
> So hopefully JSON does not change in future, only the description of JSON.
> That is not the same as saying that JSON meets all possible current and
> future protocol needs. It does not. It is not possible to pass binary data
> efficiently for a start and using decimal for floating point representation
> is likely to make the format unacceptable for serious data applications
> since it introduces conversion errors.
> The next question is whether those unmet needs should be addressed by an
> entirely new encoding with a completely new syntax and structure or whether
> we could extend the JSON model. My view is that we should do the second.

This seems entirely reasonable, so long as this extension is not called
"JSON" (assuming it adds new grammar productions). Hence the request to
normatively cite ECMA-404 and re-name any IETF-produced spec to reflect
that it is intended to be a media-type registration (or extension document
for protocol authoring, etc.), not an alternate (and therefore perhaps
extensible) definition of JSON.

> XML is fine for documents but it is not meeting my needs as a protocol
> designer. I find XML Schema to be unnecessarily confusing and baroque, the
> schema validation features supported don't help me in application
> protocols. XML does not support binary encoding of cryptographic data or
> floating point.
> There are many data encodings on offer but I would like to be able to
> write one decoder that can consume a data stream that contains basic JSON
> data and JSON with extensions. This makes negotiating an encoding in a Web
> service easy, the consumer states which encodings are acceptable and the
> sender makes sure what is sent is compatible, downgrading the encoding to
> the level accepted if necessary.
> --
> Website: http://hallambaker.com/
Received on Tuesday, 3 December 2013 01:27:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:00 UTC