- From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
- Date: Mon, 11 Nov 2013 14:53:30 +0900
- To: Anne van Kesteren <annevk@annevk.nl>
- CC: "www-tag.w3.org" <www-tag@w3.org>
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. > (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? Regards, Martin.
Received on Monday, 11 November 2013 05:54:14 UTC