Re: [Json] Proposed minimal change for duplicate names in objects

[Stephan Beal <[e-mail]>]

On Sun, Jul 7, 2013 at 3:20 AM, Nico Williams <[e-mail]> wrote:

> We still need to decide (directly or indirectly) whether to impose dup
> name checking on all JSON parsers, even minimal-state streaming
> parsers, whether we want to impose a requirement on the parser and the
> application (so we need not mention streaming), or on the parser if
> it's not a streaming parser *and* the application if the parser is
> streaming.
>

FWIW, as a JSON library implementor, i can say that a MUST on the whole
duplicate keys issue is not going to be enforced in any of my impls. Having
to check for an existing key on every insert turns O(N) operations in to
catastrophically poor operation if the property store is not fast (and JSON
has no business specifying performance characteristics). e.g. my JSON
libraries tend to use simple key/value pair _lists_, not maps, because the
nature of JSON is (for most apps) such that it's spit out and slurped in,
but not manipulated as the basic data structure (at least not in C, where
i'm working). Streaming or not, enforcing the implied level of
infrastructure and potential performance hits which MUST  implies is not
something i plan on doing, even if it means not being fully compliant.
"Duplicate keys lead to unspecified behaviour," end of story.

names.  We've had at least a number of examples of streaming parsers
> that cannot implement such a requirement -- the whole point of
> streaming being nullified by state-keeping requirements like this one.
>  So we'd have to explicitly decide that we don't want to allow minimal
> state streaming parsers.  Might as well call for consensus on that.
>

i'm for not splitting them into categories, as this document really has no
business (IMO) specifying that level of implementation detail. Specify the
duplicate keys as poor practice leading to
unspecified/implementation-defined behaviour, and be done it.

-- 
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal