Re: [I18ndir] [art] Fwd: New Version Notification for draft-bray-unichars-04.txt

[Rob Sayre <[e-mail]>]

On Tue, Sep 19, 2023 at 5:59 AM Manger, James <
[e-mail]> wrote:

> Plenty of systems will parse the JSON "\uDEAD" to & from an internal
> string representation, but that JSON is 8 ASCII characters (including the
> quotes) – there is nothing ill-formed there. It’s far less clear to me if
> many systems will parse "<ill-formed code unit sequence for U+DEAD>" from
> five 8-bit WTF-8 code units, three WTF-16 code units, or three WTF-32 code
> units. And it’s unclear to me whether ECMA-404 *expects* anything to
> parse those.
>

Ah, but no one is advocating this. The ABNF does not represent the
transformation formats, but the Unicode  /after/ decoding. Perhaps the
document should be clearer here. For example, ECMA-404 says:

"To escape a code point that is not in the Basic Multilingual Plane, the
character may be represented as a twelve-character sequence, encoding the
UTF-16 surrogate pair corresponding to the code point. So for example, a
string containing only the G clef character (U+1D11E) may be represented as
"\uD834\uDD1E".

So, the ABNF is concerned with U+1D11E, not the ASCII escape sequences.


> No. TR17 says a Unicode 16-bit string is *(%x0-FFFF). Quite different
> from *(%x0-10FFFF).
>
> TR17 does look good.
>

I was referring to the phrase: "A string data type is simply a sequence of
code units."

Even looser than the ECMA-404 definition.

thanks,
Rob