JSON decoding

Bob Ippolito bob at redivi.com
Fri Nov 3 09:58:13 PST 2006

On 11/3/06, P T Withington <ptw at pobox.com> wrote:
> 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'.

toJSON does a better job at preserving data than toJSONString. Yes,
it's possible that you can encode data in a way such that you don't
get the same thing back out. So what? At least you get a valid

Your second point doesn't make any sense. toJSONString has no
advantage whatsoever in reconstruction than toJSON. It is unsafe,

The discussion hasn't been "should we allow custom representations"
but *how* we should allow custom representations.

> >>  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-
> string>}`?

You can do that quite easily. JSON-RPC for example. You just need to
use an appropriate decoding object hook that understands how the
objects should be decoded.


More information about the Es4-discuss mailing list