Accumulated Feedback on PRI #462

This page is a compilation of formal public feedback received so far. See Feedback for further information on this issue, how to discuss it, and how to provide feedback.


Date/Time: Fri Jan 6 16:44:32 CST 2023
Name: Markus Scherer
Report Type: Error Report
Opt Subject: UAX #31 "grandfathered character"


I just stumbled on the term "grandfathered character" in UAX #31.
We should replace that; see

- https://en.wikipedia.org/wiki/Grandfather_clause#Origin
- https://medium.com/@nriley/words-matter-why-we-should-put-an-end-to-grandfathering-8b19efe08b6a
- https://developers.google.com/style/inclusive-documentation
- https://developers.google.com/style/word-list#grandfathered

There are five occurrences in UAX #31. Suggestions:

2.5 Backward Compatibility

Unicode General_Category values are kept as stable as possible, but they can
change across versions of the Unicode Standard. The bulk of the characters
having a given value are determined by other properties, and the coverage
expands in the future according to the assignment of those properties. In
addition, the Other_ID_Start property provides a small list of characters
that qualified as ID_Start characters in some previous version of Unicode
solely on the basis of their General_Category properties, but that no
longer qualify in the current version. These are called grandfathered
characters.
-->

Just remove the last sentence.


2 Default Identifiers

Note: The UAX31-R1b requirement is typically achieved by using grandfathered
characters. See Section 2.5, Backward Compatibility. Where profiles are
allowed, management of those profiles may also be required to guarantee
backwards compatibility. Typically such management also uses grandfathered
characters.

-->

Note: The UAX31-R1b requirement is typically achieved by using a small list
of characters that qualified as identifier characters in some previous
version of Unicode. See Section 2.5, Backward Compatibility. Where profiles
are allowed, management of those profiles may also be required to guarantee
backwards compatibility. Typically such management also uses a list of
characters that qualified previously.

5.2 Case and Stability

Casing stability is also an issue for bicameral writing systems. The
assignment of General_Category property values, such as gc=Lu, is not
guaranteed to be stable, nor is the assignment of characters to the broader
properties such as Uppercase. So these property values cannot be used by
themselves, without incorporating a grandfathering mechanism, such as is
done for Unicode identifiers in Section 2.5 Backward Compatibility. That
is, the implementation would maintain its own list of special inclusions
and exclusions that require updating for each new version of Unicode.

-->

Casing stability is also an issue for bicameral writing systems. The
assignment of General_Category property values, such as gc=Lu, is not
guaranteed to be stable, nor is the assignment of characters to the broader
properties such as Uppercase. So these property values cannot be used by
themselves, without incorporating a compatibility-preserving
[stability-enforcing?] mechanism, such as is done for Unicode identifiers
in Section 2.5 Backward Compatibility. That is, the implementation would
maintain its own list of special inclusions and exclusions that require
updating for each new version of Unicode.

6 Hashtag Identifiers

The grandfathering techniques mentioned in Section 2.5 Backward
Compatibility may be used where stability between successive versions is
required.

-->

The compatibility-preserving [stability-enforcing?] techniques mentioned in
Section 2.5 Backward Compatibility may be used where stability between
successive versions is required.


Feedback above this line was reviewed during UTC #175 in April, 2023