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 13:59:34 +0800
Message-ID: <CADnb78i6ger0keUeaDOV8uQ=Du6iDpAuhsg3PT-6DYOofZHmcQ@mail.gmail.com>
To: Martin J. Dürst <duerst@it.aoyama.ac.jp>
Cc: "www-tag.w3.org" <www-tag@w3.org>
On Mon, Nov 11, 2013 at 1:53 PM, "Martin J. Dürst"
<duerst@it.aoyama.ac.jp> wrote:
> On 2013/11/11 12:08, Anne van Kesteren wrote:
>> To improve JSON interoperability the IETF should not define a more
>> restricted version of JSON than defined by Ecma-404.
>> Parsers exists that can parse "42" today and parsers that cannot parse
>> "42" today can be meaningfully upgraded to do so too. This would not
>> break those parsers, unless they depend on parsing 42 as an error,
>> which is a far more unlikely scenario than parsing it as 42 given
>> precedence.
> Maybe just a minor point in wording, but of course accepting "42" wouldn't
> break a parser that accepts it. The question is what would happen with
> applications that use such a parser, and that have been relying on the
> parser to return an error up to now.

That's what I said...

>> (Worth pondering about: what to do about a leading BOM, which
>> XMLHttpRequest and browsers allow, but neither IETF nor Ecma-404
>> allow.)
> What's the percentage of JSON with a BOM for XMLHttpRequest? What's the
> actual practice, for implementations and data, for JSON in contexts other
> than XMLHttpRequest?

I don't know.

Received on Monday, 11 November 2013 06:00:03 UTC

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