Re: additional json functionality

On Wed, Nov 13, 2013 at 1:25 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> On 11/13/2013 11:37 AM, Merlin Moncure wrote:
>>
>> Yes. and I think this is one of the major advantages of the json API
>> vs hstore: you can serialize objects that hstore cannot -- at least
>> not without extra scaffolding (at least, AIUI, I haven't fully
>> grappled with the coming hstore stuff yet). In other words, just
>> because key order and cardinality is unimportant in an associative
>> array, it does not in any way follow it is similarly unimportant for
>> object serialization.
>
> An object is an unordered collection ofz ero or more name/value
> pairs
> ...
>
> The names within an object SHOULD be unique.
>
> Forcing us to preserve order and key duplication would be a pretty effective
> barrier to any performance improvements.

SHOULD != MUST. Here is the definition of object per RFC 4627.

"An object structure is represented as a pair of curly brackets
surrounding zero or more name/value pairs (or members). A name is a
string. A single colon comes after each name, separating the name
from the value. A single comma separates a value from a following
name. The names within an object SHOULD be unique."

And SHOULD means
"3. SHOULD. This word, or the adjective "RECOMMENDED", mean that
there may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course."

As far as I'm concerned, that settles things right there. Beyond that
(although they do say 'unordered' above), as a consequence of your
argument the json strings {"a": 1, "b": 2} and {"b": 1, "a": 2} should
be considered equivalent. Another consequence is that creating
particular legal constructions should be discouraged. I disagree with
this.

This is simply not the case with many json consuming clients. It's a
nice idea but not how things work universally and that's exactly why
the rules were hedged in the RFC. I have a couple of cases right now
where I'm producing key order sensitive json for some (admittedly not
very well designed) json consuming clients that are out of my control.

merlin