Re: [Json] String comparisons -- LAST CHANCE ON PROPOSALS

[Stefan Drees <[e-mail]>]

On 2013-06-11 19:44 CEST, Paul Hoffman wrote:
> Greetings again. The following thread has died off, with two
> proposals. If none of "leave the text in the draft as-is" or the
> following proposals would be acceptable to you, please propose specific
> text that would be acceptable.
>
> --Paul Hoffman
>
> Proposal 1
> ==========
> In Section 2.5. Strings, immediately before the ABNF add:
>
> For purpose of establishing key equality, comparisons MUST be
> conducted, after all unescaping is done, by comparing numeric character
> code points. There is to be no modification of any kind to the
> characters in keys, including case-changing or combining-form normalization.
>
> For example, the following four keys MUST be considered equivalent:
>
> * "\u002F"
> * "\u002f"
> * "\/"
> * "/"
>
> Proposal 2
> ==========
> In Section 2.5. Strings, immediately before the ABNF add:
>
> For purpose of establishing key equality, comparisons MUST be
> conducted, after all unescaping is done, by comparing numeric character
> code points. There MUST NOT be any modification of any kind to the
> characters in keys, including change of case or change between
> precomposed and decomposed forms.
>
> For example, the following four keys MUST be considered equivalent:
>
> * "\u002F"
> * "\u002f"
> * "\/"
> * "/"
>

I do not know what the most convenient form of the proposal I want to 
make in this case is:
In both proposals above (1 and 2) the terms "key" and "keys" are used, 
where I propose to use "name" and "names" respectively instead.

We had IMO a lot of "whishful thinking" lately that seemed to start by 
replacing the word "name" in the current JSON RFC with "key" and based 
on this transform some participants were trying to go further and 
further until maybe the paradise of uniqueness constraints finally would 
have been reached by all of us ;-)

All two occurences of the term "key" inside the RFC 4627 are related to 
RFC2119 unless I overlooked something. JSON uses the term "name" for the 
first part of those pairs that form the members of objects.

So I'll give a parametrized proposal form a try, but please advice me if 
there is a better way to accomplish this:

Proposal 3
==========

Use either the Proposal 1 or Proposal 2 but with the paragraph beginning 
as "For purpose" having replaced the terms "key" and "keys" with the 
terms "name" and "names" respectively wherever they occur therein.

All the best,
Stefan.