Pseudo-JSON with unquoted property names

David-Sarah Hopwood david-sarah at jacaranda.org
Fri Jun 5 20:57:55 PDT 2009


David-Sarah Hopwood wrote:
> Robert Sayre wrote:
>> On Fri, Jun 5, 2009 at 11:08 PM, David-Sarah
>> Hopwood<david-sarah at jacaranda.org> wrote:
>>> Robert Sayre wrote:
>>>> Also, this change would require changing the sniffing algorithm given
>>>> in section 3 of the JSON RFC.
>>>
>>> The sniffing algorithm isn't applicable here because the input is always
>>> UTF-16.
>>
>> If it is served as application/json, the media type defined by the
>> RFC, how would a compliant client transform it to UTF-16?
> 
> Ah, you are right. I concede the point.

Hang on, no I don't. The primary issue we are concerned with here is
breakage of some currently working system when someone tries to switch
it to use the JSON2 API. For such a system to have previously worked,
then whatever heuristic it was using to transform the input to UTF-16
must have been adequate for the particular JSON output by that server.
It is certainly plausible that this JSON might never start with "{X"
where X is an unquoted identifier character, even though it contained
unquoted property names later on. Alternatively, the system might have
used fixed encodings, in which case sniffing would not have been needed.


Regardless, we're obviously getting to the point of diminishing returns
with this thread, and the tide of opinion is clearly against me. I am
actually quite happy to see ES5 specify only a strictly valididating JSON
parser, and we'll see whether that results in too many interoperability
problems in practice.

(This applies to accepting unquoted property names. The other point about
escaping various control and format-control characters is an application
of Postel's conservativity rule, which should be completely
uncontroversial.)

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com



More information about the es5-discuss mailing list