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

Re: JSON feedback we could submit

From: Anne van Kesteren <annevk@annevk.nl>
Date: Mon, 11 Nov 2013 15:06:32 +0800
Message-ID: <CADnb78in_wiS0k7UY=VDke2ErEX120W0XuDRD5rM7MUrsEXQiA@mail.gmail.com>
To: Tim Bray <tbray@textuality.com>
Cc: "www-tag.w3.org" <www-tag@w3.org>
On Mon, Nov 11, 2013 at 2:29 PM, Tim Bray <tbray@textuality.com> wrote:
> On Sun, Nov 10, 2013 at 7:08 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> To improve JSON interoperability the IETF should not define a more
>> restricted version of JSON than defined by Ecma-404.
> The problem is that the IETF already *did* define such a restricted version,
> RFC4627, in 2006.  So the interesting argument is whether, in 2013, any
> increased gain in interoperability due to removing the restriction
> overbalances the software pain of people who implemented “JSON Text” per
> 4627.
> My own feeling is probably influenced by my JSON experience, largely with
> usages in application-level network messaging protocols, usually RESTful in
> flavor. In this context the interoperability of JSON is superb, and
> basically all such protocols require that messages be objects (more
> commonly) or arrays (less so). So my inclination would be to retain things
> as they are.

Those sound like specific application restrictions on top of JSON.
There's no reason they cannot continue to enforce those restrictions,
just like some will require particular keys on the object returned,

> Also, the interop problems I’ve observed have all been around dupe keys,
> busted unicode, and programmers not understanding how computers store
> numbers [sad but true].

That sounds like there's nothing blocking this.

> Also there’d probably be IETF community pushback against the -bis
> introducing an active incompatibility with the 4627, which the WG charter
> strongly discourages.

We should design formats around merit.

> But it wouldn’t be insane to raise the issue in IETF last call, which should
> be starting soon.


>> (Worth pondering about: what to do about a leading BOM, which
>> XMLHttpRequest and browsers allow, but neither IETF nor Ecma-404
>> allow.)
> Yeah.  Maybe spirit-of-Postel’s-law language urging implementors of
> generators to avoid these things where possible, and implementors of parsers
> to tolerate them where possible?

Sounds good.

Received on Monday, 11 November 2013 07:06:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:59 UTC