JSON decoding

P T Withington ptw at pobox.com
Fri Nov 3 09:49:31 PST 2006

On 2006-11-03, at 10:14 EST, Bob Ippolito wrote:

> On 11/3/06, P T Withington <ptw at pobox.com> wrote:
>> I think we have this upside down.  We're worried about the user
>> creating an invalid JSON string.  Why?  Because they could break the
>> reader?  Doesn't the reader have to protect itself?  (Perhaps the
>> lure of eval as a reader has confused us.)
> The proposal definitely doesn't use eval as a reader.

I was referring to http://www.json.org/json.js  I understood the  
original motivation for JSON was that all Javascripts already had a  
built-in (although unsafe) JSON parser in the form of eval, whereas  
not all of them had functional XML parsers.  If I am wrong, my  
parenthetical remark is not crucial to my questions.

>> It seems more important to tell the user:  'You tried to create a
>> JSON representation of something, but it can't be represented in a
>> way that parseJSON can meaningfully reconstruct it".
> The problem is injection attacks and intermittent brokenness based on
> input values.

I understand that the 'from JSON' mechanism must protect itself  
against such.  But there is no point in preventing the 'to JSON'  
mechanism from writing such, since 'from JSON' must validate  
anyways.  More important is to signal an error if an object that  
cannot be round-tripped is passed to 'to JSON'.  The end user would  
be justifiably upset if 'to JSON' gave the impression that it  
preserved their data, only to find out (much) later that 'from JSON'  
cannot reconstruct it.  These are almost the same condition, but  
there is an important difference in emphasis:  rather than preventing  
the user from using 'to JSON' in a way that breaks 'from JSON', you  
are preventing the user from writing data using 'to JSON' that can  
not be reconstructed accurately using 'from JSON'.

>>  From an historical point of view, perhaps we are trying to do too
>> much with JSON.
>> JSON reminds me of Lisp's print/read, which eventually evolved a flag
>> [*print-readably*](http://www.lisp.org/HyperSpec/Body/var_stprint-
>> readablyst.html#STprint-readablyST).  If true, you will get an error
>> if you try to print an object that cannot be represented in a way
>> that read can parse and construct a 'similar' object.  Print/read
>> relies, as does JSON, on the implicit type-encoding of the language
>> literals.
>> toJSON seems like 'half a loaf'.  It lets me encode an arbitrary
>> object, but without a corresponding fromJSON, what use is it?
> The whole load is there, just not in this particular implementation.
> The object of current discussion was encoding, not decoding, so I
> didn't implement a whole parser.
> (from Brendan's email on the 20th)
>    * String.prototype.parseJSON( hook )
> Returns the value represented by the string. A syntaxError is thrown
> if the string was not a strict JSON text.
> The optional hook function will be called for each object value
> found. It is passed each object. Its return value will be used
> instead of the object in the final structure.

I understand this to mean that you intend to support building, on top  
of the JSON substrate, a general dump/load that would preserve  
arbitrary values, not just those that can be directly represented as  
literals.  I don't quite see how you can do that, since it would mean  
that you would have to use some part of the literal space that can be  
represented by JSON to represent these additional values.  At the  
very least, you need to define an escape in JSON to do that, no?   
Otherwise how do you distinguish between a literal that represents,  
say, an instance of a class, and the same pattern meant to represent  
just that literal value?  As a concrete example, if we did not have  
date literals and you chose to implement 'to JSON' of a date object  
as `{date: <iso-date-string>}`, how can 'from JSON' tell whether it  
is to reconstruct a Date vs. reconstruct the Object `{date: <iso-date- 

More information about the Es4-discuss mailing list