JSON specification WAS: Re: JSON Duplicate Keys
gazheyes at gmail.com
Thu Jun 6 06:00:14 PDT 2013
Since Doug is here I thought I'd use the opportunity to discuss the broken
this broke the JSON specification. The code sample used within the RFC is
also broken since line/para separators would cause eval to fail. It needs
to be fixed IMO. While taking this opportunity to fix the specification by
forcing line/para to unicode escapes e.g \u2028, \u2029 we should also
force "<" into \x3c and ">" into \x3e. I propose the following changes:
1. Remove the awful invalid code sample.
2. The string section instead of "Any character may be escaped." there
should be some exceptions. < and > must be encoded with hex/unicode
escapes. Line/Para separators must be encoded to unicode escapes and
finally right-to-left and left-to-right mark should also required to be
encoded in unicode escapes.
I think we also need to discuss the keywords present in json keys for
Should proto be a banned keyword in JSON keys? I think giving data the
ability to control it's type could break things when it's used elsewhere.
There is also an argument for requiring hex escapes for characters lower
than 0x09 but I guess a lot of people will be against that.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss