JSON specification WAS: Re: JSON Duplicate Keys
gazheyes at gmail.com
Thu Jun 6 06:43:08 PDT 2013
On 6 June 2013 14:25, Jeremy Darling <jeremy.darling at gmail.com> wrote:
> Thinking about this for JSON that means that if you were wanting to
> serialize a complete object (prototype, setters, getters, etc) you would
> have a standard symbol for stating "This is a control key" then dev's would
> have to code for all possible key words in their escape/unescape sequence.
> Or the spec would have to be amended to contain some type of
> "isReservedKey" statement. This just introduces a whole new can of worms
> and more breaking points.
Yeah I agree it's a can of worms but I wanted to throw it out there for
discussion. As we get more keywords and functionality it could bite in the
butt in a few years time.
I don't exactly understand your point in bullet 2? Why do < and > have to
> be encoded, they are perfectly valid values inside of a string today, and
> again many libraries make use of this functionality for transporting HTML,
> XML, and Text fragments. To Crockfords point, "should not break" becomes
> the issue with changing what should and should not be encoded.
For two reasons 1) Some browsers will render json as html (sniffing) 2)
Inline JSON data will be parsed in a different order than it's intended.
and > will have no effect on passing xml/html data but will prevent those
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss