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

Re: JSON feedback we could submit

From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
Date: Mon, 11 Nov 2013 15:43:52 +0900
Message-ID: <52807CA8.1030103@it.aoyama.ac.jp>
To: Anne van Kesteren <annevk@annevk.nl>
CC: "www-tag.w3.org" <www-tag@w3.org>
On 2013/11/11 14:59, Anne van Kesteren wrote:
> 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...

Yes. But telling the IETF that it's okay to change the definition 
because it doesn't break parsers when the question is what happens to 
applications won't help convince the IETF.

Regards,  Martin.


>>> (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:44:36 UTC

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