> On Aug 13, 2016, at 2:33 AM, Marcel Schneider <[email protected]> wrote: > > On Sat, 13 Aug 2016 09:29:05 +0200, Philippe Verdy wrote: > […] >> I see little interest to force anyone to use the U+NNNN NAME convention >> everywhere, as it is overlong and may instead obscure the discussions. Even >> when it is used, the NAME will be frequently abbreviated (such as dropping >> the >> script name prefix or common words such as LETTER or DIGIT). And given that >> character names are not case-significant, they will be frequently written >> using lowercase, or mixed case, or just by presenting the verbatim character >> itself. >> > One advantage I see in using capitalized character names is in making them > unambigously recognizable as identifiers, in order to prevent readers from > mistaking them as descriptors. > > However I admit that I often unify casing pairs by dropping the CAPITAL and > SMALL attributes, as in LATIN LETTER AE, but it would be more accurate to > write > LATIN CAPITAL/SMALL LETTER AE. By contrast I wouldnʼt do that when referring > to > the LATIN CAPITAL and SMALL LIGATURE OE, because the term “ligature” is an > abusive > relict enforced by the ISO redactor at the time, and set back to “letter” in > the > case of the Æ (as discussed past year). Here the advantage of using a > translation > is to be able to correct without risking confusions. > > Another advantage is in highlighting the names against the surrounding text. > Avoiding uppercase—e.g. from people hating their Caps Lock toggle key, who > Iʼve read they do exist but are very uncommon in the country where we live— > would need workarounds like using quotation marks, which in this context are > almost always misleading. > > As of the U+ notational prefix for current text, I see it as extremely useful > and I always apply it except, as Philippe states, in some tabular data, > which is but following the pattern used in the NamesList (which Iʼm keeping > constantly opened in my text editor). > > Using the U+ prefix throughout has the additional advantage of promoting > Unicode in the mind of people—an urgent challenge, […]
Thank you. I have been reviewing draft-iab-rfc-nonascii-02 <https://tools.ietf.org/html/draft-iab-rfc-nonascii-02>, which formally opens the RFC series to UTF-8 encoded characters. (Look at the PDF version, which shows characters beyond the ASCII range.) I was surprised that Section 3.4 provides no less than *six* notational alternatives, none of which conform to Appendix A of TUS. There might be valid grammatical reasons to notate differently than Appendix A, but I would think that Appendix A style U+2206 INCREMENT would be the best choice, as in: 1. Temperature changes in the Temperature Control Protocol are indicated by "Δ" U+2206 INCREMENT. where U+ NAME replaces the part-of-speech “the XYZ character”, the character itself is quoted directly in front of the U+, and parentheses are not needed. (I am actually in favor of curly quotes “Δ” in such a case, but that discussion should probably be had in the IETF.) Interestingly, TUS 9.0.0 is not internally consistent, but there is a trend that when the character is quoted, it is put in curly quotes and is placed between the U+ syntax and the NAME, as in: Section 3.13 Uppercasing of U+00DF “ß” latin small letter sharp s to … Section 5.21 U+2061 Ê function application has no effect on the text display… (Note: the Ê character appears in TUS as f() in a box…I am copying and pasting the text directly on my Mac from Acrobat to Mail.app. And, obviously, it’s copying and pasting the small-caps in lowercase.) In plain text, ALL-CAPS names are superior to mixed case or lowercase names. However, in stylized text, small-caps not only looks better but offers a more convenient visual and semantic way to differentiate the part-of-speech. I may have to suggest that small-caps be added as a stylistic element to the new xml2rfc format, or, that a new element be provisioned specifically to identify Unicode code points, which automatically get stylized appropriately to the output format (ALL-CAPS for plain text, stylized small-caps for marked up text). Sean
