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
document.

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

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.

-bob



More information about the Es4-discuss mailing list