On Fri, Mar 08, 2013 at 10:34:20PM +0100, Hannu Krosing wrote:
> On 03/08/2013 10:01 PM, Alvaro Herrera wrote:
>> Hannu Krosing escribi?:
>>> If it does not meet these "semantic" constraints, then it is not
>>> really JSON - it is merely JSON-like.
>> Is it wrong? The standard cited says SHOULD, not MUST.
>
>
> I think one MAY start implementation with loose interpretation of
> SHOULD, but if at all possible we SHOULD implement the
> SHOULD-qualified features :)
>
> http://www.ietf.org/rfc/rfc2119.txt:
>
> 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.
That "SHOULD" in section 2.2 of RFC 4627 constrains JSON data, not JSON
parsers. Section 4 addresses parsers, saying "A JSON parser MUST accept all
texts that conform to the JSON grammar."
> We might start with just throwing a warning for duplicate keys, but I
> can see no good reason to do so. Except ease of implementation and with
> current JSON-AS-TEXT implenetation performance.
Since its departure from a "SHOULD" item does not impugn the conformance of an
input text, it follows that json_in(), to be a conforming JSON parser, MUST
not reject objects with duplicate keys.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
