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. -- http://annevankesteren.nl/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