Re: [Json] On characters and code points

[Paul Hoffman <[e-mail]>]

On Jun 8, 2013, at 2:38 AM, Carsten Bormann <[e-mail]> wrote:

> On Jun 7, 2013, at 17:56, Paul Hoffman <[e-mail]> wrote:
> 
>> Remove the word "character" from the spec except in an explanatory paragraph in Section 2.5 that says:
>>  All code points, even those that represent non-characters in the Unicode specification [UNICODE], are allowed in JSON strings.
> 
> A much better way to handle this problem would be
> 
> "For the purposes of this specification, the term "character" includes both Unicode characters and ______."
> 
> Fill in the blanks based on what we want to do here:
> 
> (1) I think it is now clear that we don't want to shun Unicode non-characters (see corrigendum #9).
> 
> (2) I think it is also clear that we want to include all Unicode code positions that could become Unicode characters in future versions of Unicode according to the compatibility spec.
> 
> (3) I also think that we don't want to change UTF-8, the UTF-16s, or the UTF-32s, so what's possible in "native" encoding will be controlled by those specifications, minus ", \, the C0 characters.
> 
> (4) The remaining question appears what we do with unpaired escaped surrogates.
> The answer will have to be a bit wishy-washy, because anything strong will invalidate half of the implementations.  If is probably a good idea not to "break" those applications that compensate JavaScript's lack of a binary string type by using UTF-16 as a vector of unconstrained 16-bit values, but we also cannot mandate that everyone adopt this 1990s style hack.

Ummm, how is that "much better"? "Code points minus THEONESWEHATE" seems a lot simpler than "characters plus ADDITIONAL1 plus ADDITIONAL2 plus ADDITIONAL3".

--Paul Hoffman