Subject: [Json] Proposal for duplicate names in objects for next draft

From: Paul Hoffman <[email-masked]>
Date: Fri, 6 Sep 2013 14:12:04 -0700

Greetings again. The WG chairs are continuing the effort to get specific wording for the next draft so that people will be able to see all the proposed text changes together so that we can continue to hone each one. We have recently done "numbers and precision" and "text model", and it's time to do "objects and duplicate names".

The following text reflects a summary that most recently seemed to enjoy general agreement. Does anyone have any strong objection to adding the following to the draft?

An object whose names are all unique will be interoperable in the sense that all software that receives that object will represent the object the same way. When the names within an object are not unique, the behavior of software that receives such an object is unpredictable. Many implementations report the last name/value pair only; other implementations report an error or fail to parse the object; other implementations report all of the name/value pairs, including duplicates. 

--Matt Miller and Paul Hoffman

---

From: John Cowan <[email-masked]>
Date: Fri, 6 Sep 2013 17:14:50 -0400

Paul Hoffman scripsit:

> An object whose names are all unique will be interoperable in the
> sense that all software that receives that object will represent
> the object the same way. When the names within an object are not
> unique, the behavior of software that receives such an object is
> unpredictable. Many implementations report the last name/value pair
> only; other implementations report an error or fail to parse the
> object; other implementations report all of the name/value pairs,
> including duplicates.

I think for "unique" read "distinct", as "unique" could be misinterpreted
as "globally unique".

-- 
John Cowan  http://ccil.org/~cowan  [email-masked]
All "isms" should be "wasms".   --Abbie

---

From: Tim Bray <[email-masked]>
Date: Fri, 6 Sep 2013 14:16:42 -0700

“will represent the object the same way” is too strong.  I suggest instead

... in the sense that all software that receives that object will agree on
the name-value mappings.

On Fri, Sep 6, 2013 at 2:12 PM, Paul Hoffman <[email-masked]> wrote:

> Greetings again. The WG chairs are continuing the effort to get specific
> wording for the next draft so that people will be able to see all the
> proposed text changes together so that we can continue to hone each one. We
> have recently done "numbers and precision" and "text model", and it's time
> to do "objects and duplicate names".
>
> The following text reflects a summary that most recently seemed to enjoy
> general agreement. Does anyone have any strong objection to adding the
> following to the draft?
>
> An object whose names are all unique will be interoperable in the sense
> that all software that receives that object will represent the object the
> same way. When the names within an object are not unique, the behavior of
> software that receives such an object is unpredictable. Many
> implementations report the last name/value pair only; other implementations
> report an error or fail to parse the object; other implementations report
> all of the name/value pairs, including duplicates.
>
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Fri, 6 Sep 2013 21:29:52 +0000

> I think for "unique" read "distinct", as "unique" could be misinterpreted

/me dons hat

I will note that RFC 4627 uses the term "unique".  Do you think it's necessary changing all (one) instances of "unique" to "distinct" in 4627bis?

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

---

From: John Cowan <[email-masked]>
Date: Fri, 6 Sep 2013 17:32:53 -0400

Matt Miller (mamille2) scripsit:

> I will note that RFC 4627 uses the term "unique".  Do you think it's
> necessary changing all (one) instances of "unique" to "distinct"
> in 4627bis?

I think that would be a Good Thing, yes.  That would change the last
sentence of 2.2 to:

   The names within an object SHOULD be distinct.

-- 
A rabbi whose congregation doesn't want         John Cowan
to drive him out of town isn't a rabbi,         http://www.ccil.org/~cowan
and a rabbi who lets them do it                 [email-masked]
isn't a man.    --Jewish saying

---

From: Stefan Drees <[email-masked]>
Date: Sat, 07 Sep 2013 07:45:28 +0200

>     The names within an object SHOULD be distinct.

I second to move away from the slippy unique, and embrace distinct but 
suggest to add pairwise, thus:

     The names within an object SHOULD be pairwise distinct.

---

From: Stefan Drees <[email-masked]>
Date: Sat, 07 Sep 2013 07:51:42 +0200

On 2013-09-06 23:12 +02:00, Paul Hoffman wrote:
> ...
> that all software that receives that object will represent the object
> the same way. When the names within an object are not unique, the
> behavior of software that receives such an object is unpredictable. Many
> implementations report the last name/value pair only; other
> implementations report an error or fail to parse the object; other
> implementations report all of the name/value pairs, including duplicates.

I suggest - in unison with Tim Bray's proposal and my amendment to John 
Cowan's proposal - to change the first sentence of above paragraph into:

An object whose names are pairwise distinct will be interoperable in the 
sense that all software that receives that object will agree on
the name-value mappings.

---

From: Matthew Morley <[email-masked]>
Date: Mon, 9 Sep 2013 11:28:39 -0400

>    The names within an object SHOULD be distinct.

+1 (sent to the actual list this time)

-- 
Matthew P. C. Morley

---

From: "Pete Cordell" <[email-masked]>
Date: Tue, 17 Sep 2013 10:35:00 +0100

I don't feel that "distinct" is the best choice of words. 
http://www.thefreedictionary.com/distinct gives the following definitions 
for distinct:

dis·tinct  (d-stngkt)
adj.
1. Readily distinguishable from all others; discrete: on two distinct 
occasions.
2. Easily perceived by the senses or intellect; clear: a distinct flavor.
3. Clearly defined; unquestionable: at a distinct disadvantage.
4. Very likely; probable: There is a distinct possibility that she won't 
come.
5. Notable: a distinct honor and high privilege.

For some reason definitions 2 and 3 are what I most naturally think of when 
someone says "distinct".  Would "locally unique" be a better choice?  Or 
maybe just use "different":

    The names within an object SHOULD be different.

and:

    An object whose names are all different will be interoperable in the
    sense that all software that receives that object will represent
    the object the same way. When the names within an object are not
    different, the behavior of software that receives such an object is
    unpredictable. Many implementations report the last name/value pair
    only; other implementations report an error or fail to parse the
    object; other implementations report all of the name/value pairs,
    including duplicates.

Pete Cordell
Codalogic Ltd
C++ tools for C++ programmers, http://codalogic.com
Read & write XML in C++, http://www.xml2cpp.com
----- Original Message ----- 
From: "Stefan Drees" <[email-masked]>
To: "John Cowan" <[email-masked]>
Cc: <[email-masked]>; "Paul Hoffman" <[email-masked]>; "Matt Miller 
(mamille2)" <[email-masked]>
Sent: Saturday, September 07, 2013 6:45 AM
Subject: Re: [Json] Proposal for duplicate names in objects for next draft

---

From: Tim Bray <[email-masked]>
Date: Tue, 17 Sep 2013 13:09:28 -0700

Actually, it might be simpler to turn it around:

An object where the names constitute a set, i.e. no two of them are equal,
will be interoperable in the sense..

And if we decide to write string comparison rules into the -bis, put a
reference to that next to the word “equal”. -T

On Tue, Sep 17, 2013 at 2:35 AM, Pete Cordell <[email-masked]>wrote:

> http://www.thefreedictionary.**com/distinct<http://www.thefreedictionary.com/distinct>gives the following definitions for distinct:
>
> dis·tinct  (d-stngkt)
> adj.
> For some reason definitions 2 and 3 are what I most naturally think of
> when someone says "distinct".  Would "locally unique" be a better choice?
>  Or maybe just use "different":
>
> ----- Original Message ----- From: "Stefan Drees" <[email-masked]>
>> ______________________________**_________________
>> json mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/json<https://www.ietf.org/mailman/listinfo/json>
>>
>
> ______________________________**_________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/json<https://www.ietf.org/mailman/listinfo/json>
>

---

From: John Cowan <[email-masked]>
Date: Tue, 17 Sep 2013 16:29:05 -0400

> will be interoperable in the sense..

No, no.  Saying "If you do this it's broken" is not equivalent to
"If you don't do this it works", for after all it may be broken (not
interoperable) for some other reason.

-- 
Almost all theorems are true,                   John Cowan <[email-masked]>
but almost all proofs have bugs.                http://www.ccil.org/~cowan
        --Paul Pedersen

---

From: Stephen Dolan <[email-masked]>
Date: Wed, 18 Sep 2013 13:50:19 +0100

>    The names within an object SHOULD be different.

I see your point, but that still reads oddly to me. After reading that
sentence, I ask "different from what?". How about:

    An object SHOULD NOT use the same name more than once.

>    object; other implementations report all of the name/value pairs,

The first sentence seems wrong. All software that receives an object will
definitely not represent the object the same way. Slightly reworded:

When an object uses a given name twice, the behaviour of software that
receives it is unpredictable. Many implementations report the only the last
name/value pair which uses a given name; other implementations report
an error or fail to parse the object; while other implementations report all
of the name/value pairs, including those that share a name.

Also, are implementations really allowed to reject such an object? I
am not sure what the consensus is here.

Stephen Dolan

---

From: "Pete Cordell" <[email-masked]>
Date: Thu, 19 Sep 2013 10:22:47 +0100

Original Message From: "John Cowan"
> interoperable) for some other reason.

Looking back, I think "distinct" was first suggested in the following 

> I think for "unique" read "distinct", as "unique" could be misinterpreted

Looking at that, there's a case for saying "An object whose names ..." is 
ambiguous because "names" could be read as referring to the name of the 
objects themselves rather than the members therein.

Therefore, would the scope of the uniqueness be clarified if the opening 
sentence was changed to:

"An object whose members' names are all unique..."?

Pete Cordell
Codalogic Ltd