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

[Stefan Drees <[e-mail]>]

On 2013-06-07 11:04, Markus Lanthaler wrote:
> On Friday, June 07, 2013 2:14 AM, Nico Williams wrote:
>> On Jun 6, 2013 6:09 PM, "Markus Lanthaler" <[e-mail]> wrote:
>>>
>>> On Sent: Friday, June 07, 2013 12:22 AM, Nico Williams wrote:
>>>> Having thought this far, I propose this text:
>>>>
>>>>     Encoders SHOULD NOT send duplicate keys.  Some encoders might not
>>>> be able to prevent duplicate keys.  Therefore parsers MUST be prepared
>>>> to handle duplicate keys.
>>>
>>> -1, it is very reasonable to reject such JSON.
>>
>> I wrote "handle", not "accept".
>
> If your "handle" implies that an error might be raised then it would
> be OK but I believe most people wouldn't understand it that way.

weighting the part following the "but" I read (and second) this as -1

In case TL;DR please goto "TL;DR"

Three further remarks ignited in me by the above text (that was proposed 
by Nico Williams):

"""
Encoders SHOULD NOT send duplicate keys.  Some encoders might not
be able to prevent duplicate keys.  Therefore parsers MUST be prepared
to handle duplicate keys.
"""

Which b.t.w. I would certainly rewrite as:

NEW
"""
Generators SHOULD NOT duplicate names in objects.  Parsers MUST be 
prepared to either accept duplicate names in objects or reject the 
complete JSON text containing these, as a generator might not avoid nor 
detect such duplication.
"""

"TL;DR":
Above is my proposal if we really want to change the current wording and 
if we settle on the terms generator and parser. Otherwise replace with 
encoder and decoder ;-)

Now for something completely different (the promised remarks):

A) encoders relate to parsers?

There seem to be some projections of the spec we really need to check 
periodically, so not "hypernyms" slip in ...

Let us please not cross-mix members of dimensional pairs:

* ("encoder","decoder")
* ("accept","reject")
* ("interpret","ignore")
* ("generator","parser")
* ("producer","consumer")
* ("sender","receiver")
* ("service","client")
* ...


B) We can "handle" anything :-)

The verb "handle" IMO is related to far too many possible actions:
accept, reject, interpret, ignore all jump to my mind, when I'm 
requested to handle something.

On a more higher level the robustness principle (a.k.a. Postel’s law) 
cf. [RFC1122]: "Be liberal in what you accept, and conservative in what 
you send" (*) might at first glance help advice the participants in the 
lax historically grown state we're, **but**

1. we now have all kind of JSON consumers ranging from the brittle 
("picky") to the robust ("close to blind").

2. we define a format, and not a "JSON service" or the like

As I understood, we do not change practical usage of the spec, but on 
occasion of augmenting the RFC to STD and avoiding a cyclic normative 
referencing between JSON RFC and ECMAScript spec we perform "some non 
interupting hygienic actions".

So I think there will be only microscopic changes (compared to the old 
RFC) on this topic left over after consensus calls.


C) "names" are not "keys"

Again in above text (and at the heart of the discussion IMO) we take the 
"name"s of the object members as "key" but do not say so in the RFC, and 
did not in the original.

This semantic difference and the historical fact that it was not spelled 
out in the original RFC gently directs us to just leave the "names" 
condition as is, and not start expressing our whishful thinking, we 
could simply rename these as "key" and have all the uniqueness readily 
at hand.


References:

[RFC1122]: Braden, R., Ed., "Requirements for Internet Hosts -
            Communication Layers", STD 3, RFC 1122, October 1989.
            http://www.ietf.org/rfc/rfc1122.txt.

*): I know RFC791 is historically the first similar mention, but it is 
obsoleted as RFC, so ...

All the best,
Stefan.