Brian Mitchell wrote:
> On Tue, Sep 29, 2009 at 14:14, Caleb Clausen <caleb / inforadical.net> wrote:
>> Tim Bray wrote:
>>> Per RFC4267, http://www.ietf.org/rfc/rfc4627.txt, "foo" isn't legal JSON.  Top level has to be an object {} or array [].  So unparse should refuse to process "foo".  This isn't just a theoretical standards-wonk problem, I got bitten trying to interop with Java JSON libraries on this one.
>> Do you (or anyone else) have any idea why it was specified this way? It
>> seems kind of inconvenient.
> 
> JSON is designed for sending structured data. Being a glorified format
> for just a string seems like overkill. I recommend wrapping it in an
> object or array in any case because if it is just a string it seems
> like it lacks that self-describing aspect of well structured data.

In the general case, if I want use json to serialize+deserialize objects
(where the precise type isn't specified ahead of time), then I don't
want to be bothered with restrictions like this. I don't like having to
always wrap my data in an array just because I might want to encode a
string.

I should think Json ought to handle all objects equally... whether their
actual class be Array, Hash, String, or Fixnum. Granted, there will be
some restrictions imposed by the fact that JSON is a subset of
JavaScript, so some concepts just aren't available. For instance,
JavaScript has no symbols, so there's no way ruby's Symbol is going to
be perfectly supported in JSON. But why should that apply to Strings?

To put it another way, lack of structure is itself a kind of structure.

Having said all that, I'd like to thank Kornelius Kalnbach for revealing
the reason(s) why it is the way it is. I might prefer it a different
way, but at least there is a valid reason.