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

[Nico Williams <[e-mail]>]

On Sat, Jul 6, 2013 at 8:44 PM, Tim Bray <[e-mail]> wrote:
> This feels like a no-brainer to me, but that’s probably because (as I’ve
> said before) I’m an API guy, and the only use for JSON objects in my world
> is to transfer a hash table or database record or whatever from here to
> there, and there, and in such a situation dupes can never be useful or
> intended and can only be a symptom of breakage (or, in the JOSE case, a
> symptom of a malicious attack on my crypto).

I agree.  As a security guy I would prefer if one way or another we
end up with no dup names, but as an "API guy" myself I think of the
streaming parsers (they offer an API after all).  Just say the magic
words: "to hell with minimal state streaming parsers" or perhaps
something to the effect that *some* component of a layered application
MUST reject objects with dup names.  It's either or.  Let's choose.

I'm happy with "some component of a layered application MUST reject
objects with duplicate names" -- I prefer this to the "no minimal
state streaming parsers" alternative.

I will assume that in general objects rarely have lots of names, so
that parsers need not keep that much state in order to check for dups.
 Requiring parsers to reject objects with dup names is my second
choice.

Nico
--