Re: Proposal: Add JSON support

On Mon, Apr 5, 2010 at 11:50 PM, Joseph Adams
<joeyadams3(dot)14159(at)gmail(dot)com> wrote:
> Another JSON strictness issue:  the JSON standard (
> http://www.ietf.org/rfc/rfc4627.txt ) states that JSON text can only
> be an array or object.  However, my implementation currently accepts
> any valid value.  Thus, '3', '"hello"', 'true', 'false', and 'null'
> are all accepted by my implementation, but are not strictly JSON text.
>  The question is: should the JSON datatype accept atomic values (those
> that aren't arrays or objects) as valid JSON?
>
> I tried a few other JSON implementations to see where they stand
> regarding atomic types as input:
>
> JSON_checker (C) does not accept them.
> JSON.parse() (JavaScript) accepts them.
> json_decode() (PHP) accepts them.  However, support is currently buggy
> (e.g. '1' is accepted, but '1 ' is not).
> cJSON (C) accepts them.
> JSON.pm (Perl) accepts them if you specify the allow_nonref option.
> Otherwise, it accepts 'true' and 'false', but not 'null', a number, or
> a string by itself.
>
> In my opinion, we should accept an atomic value as valid JSON content.
>  I suppose we could get away with calling it a "content" fragment as
> is done with XML without a doctype.
>
> Accepting atomic values as valid JSON would be more orthagonal, as it
> would be possible to have a function like this:
>
> json_values(object_or_array JSON) RETURNS SETOF JSON
> -- extracts values from an object or members from an array, returning
> them as JSON fragments.
>

For these reasons, and the fact that my project uses atomic values ;),
I think yes, we should support them.

IIUC, the reason for requiring an array or object is that the O part
of JSON means "some sort of a collection of atomic values". But, in
ECMAScript (JavaScript), instances of strings, numbers, bools and null
are, indeed, objects. IOW, I think JSON is using a faulty definition
of "object" in the spec. It's the one part of the spec that doesn't
make sense to me at all.

> Also, should we go even further and accept key:value pairs by themselves? :
>
> '"key":"value"'::JSON
>

This, though, is probably a step too far. It violates the JS part of JSON ...

> I don't think we should because doing so would be rather zany.  It
> would mean JSON content could be invalid in value context, as in:
>
> // JavaScript
> var content = "key" : "value";
>

Right.

Thanks, Joseph. I think this will be a great addition!

--
Mike Rylander
| VP, Research and Design
| Equinox Software, Inc. / The Evergreen Experts
| phone: 1-877-OPEN-ILS (673-6457)
| email: miker(at)esilibrary(dot)com
| web: http://www.esilibrary.com