Re: [Json] Consensus call: establishing name equality

[Norbert Lindenberg <[e-mail]>]

On Jun 21, 2013, at 16:21 , Tim Bray wrote:

> On Fri, Jun 21, 2013 at 4:15 PM, Jacob Davies <[e-mail]> wrote:
> 
> Is this definition of equality needed elsewhere in the document though? Standing alone it seems a little odd - there's no discussion how to compare two numbers, two objects, or two lists for equality, so why are strings-used-for-names special?
> 
> Because 
> - We talk about duplicates so it's important to define what duplicate means

Correct - section 2.2, "The names within an object SHOULD be unique."

> - they are, in effect, hash-table keys, so comparison really matters

That seems out of scope for the spec - the spec may cover the output of the parser, but not what clients do with the output. We can't stop clients from treating names as case insensitive, for example.

However, the comment that eventually led to this proposal was actually about a somewhat different problem [1]:

> It should say explicitly that these three all produce exactly the same result:
>     "\u002F"
>     "\/"
>     "/"
> 
> I have seen confusion about this.

This comment is about how the parser interprets JSON text and what its output is. The three input strings shown, as well as "\u002f", should all result in an output string containing the single code point U+002F.

This important information seems to have gotten lost in the subsequent discussion.

To say that the four input strings must be considered equivalent then becomes unnecessary because they result in the same name.

[1] http://www.ietf.org/mail-archive/web/json/current/msg00372.html

Norbert