Re: [Json] The names within an object SHOULD be unique.

["Markus Lanthaler" <[e-mail]>]

On Wednesday, June 05, 2013 9:56 PM, Nico Williams wrote:
> On Wed, Jun 5, 2013 at 2:30 PM, Stephan Beal wrote:
>> i wouldn't quite go so far as to say it's strictly historical in nature. It
>> gives implementations leeway on what is essentially a corner case (who
>> actively generates non-unique keys?). Forcing a specific behaviour here
> 
> If no one does that then we can make a "breaking" change here that
> breaks no one, no?  (I'm being the devil's advocate here.)

I've seen people using this for comments. People relied on the fact that serializers ignored all but the last occurrence of a key.


> > could potentially leave a lot of current 100% JSON-compliant parsers
> > suddenly non-compliant because of [what i perceive as] an unusual
> > corner case. Pointing it out as a potential pitfall, sure, but i
> > wouldn't claim that it's "historical baggage."
> 
> There's no compliance police here.  If some change merely leaves us
> with non-compliant implementations then maybe I don't care, after all
> they'd still compliant with the old RFC and could be updated to be
> compliant with the new one.  But we mustn't break interoperability any
> more than it already was.  If indeed there are senders with duplicate
> keys (and different values) that alternately get to talk to receivers
> that take the first or last key, then there's already broken interop,
> so picking one of the two should be fair game.  But I bet we have
> little real data on this, so we'll end up assuming that such a change
> can break interop.

I think we have to choose one to get interoperability. I've seen some systems that merge the values of multiple keys in an array but most do what JavaScript does, i.e., they ignore all but the last key.


I really like the proposal Eliot Lear made in another thread:

> Demonstrating my age, an old trick we've done that goes back to RFC-
> 1123 is to say MUST NOT send, and then implementations MAY NOT process,
> and if they do MUST process thusly...
> 
> That gives you the possibility of potentially getting rid of something
> at a later date.  I don't know if you want to use it here.  It only
> sometimes works.



--
Markus Lanthaler
@markuslanthaler