With my document shepherd hat on, I just reviewed
draft-ietf-precis-mappings. I have sent some editorial comments to the
authors. I also found two more substantive issues...
1. The "local case mapping" method specified in Section 2.3 talks about
locale and context. However, the example in the second paragraph is a
matter of language, not locale:
As an example of locale and context-dependent mapping, LATIN CAPITAL
LETTER I ("I", U+0049) is normally mapped to LATIN SMALL LETTER I
("i", U+0069); however, if the case of Turkish (or one of several
other languages), unless an I is before a dot_above, the character
should be mapped to LATIN SMALL LETTER DOTLESS I (U+0131).
As I understand it, locale (see Section 8 of RFC 6365) would refer to a
particular region within a language-speaking community, such as
Switzerland within the German-speaking areas.
The SpecialCasing.txt file in the Unicode standard talks about
language-sensitive mappings for the Lithuanian, Turkish, and Azeri
languages. (It also talks about a language-insensitive mapping, i.e.,
context-dependent mapping, for Greek final sigma.) It does not talk
about locale-dependent mappings for particular regions within any
language-speaking communities.
Therefore, I wonder if all mentions of locale in
draft-ietf-precis-mappings really ought to be mentions of language. On
reading the text in the document right now, I provisionally concluded
that this switch would make sense, but I haven't thought carefully about
every instance. And I would be curious to hear from the authors and
working group about this issue.
2. Appendix B purports to describe why local case mapping needs to be an
alternative to Unicode Default Case Mapping instead of being applied
sequentially (the text mentions the possibility of applying local case
mapping before Unicode Default Case Mapping - is that the only option,
or should we say something about applying it after?).
However, Appendix B only mentions eszett (U+00DF) and to my mind does
not provide a complete argument for why local case mapping needs to be
an alternative to Unicode Default Case Mapping. At the least, it might
be valuable to mention the handling of characters other than eszett. I
suppose the basic argument is already in Section 2.3, but if so then I
think that Appendix B might have a misleading title.
Other than these two issues, I think the document is in good shape
(modulo some editorial adjustments).
Peter
--
Peter Saint-Andre
https://andyet.com/
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
