On 22.11.2013 01:41, Peter Saint-Andre wrote: > On 11/21/13 2:19 PM, Florian Zeitz wrote: > >> I've reread the draft in its entirety now that some time has >> passed. I have a few minor comments (some of them nits, which >> IMHO is a good sign), but overall I'm very pleased with it and >> think all feedback has been addressed. > > Thanks for the review! > >> Generally I think we need to update the draft to Unicode 6.3. If >> we don't, at least the claims that Unicode 6.2 is the latest >> version at the time of writing should be removed ;). > > Yes, I noticed that while completing my own review earlier this > week. > >> Section 4.1.1 claims width mapping is an aspect of NFKC. While >> this is true it is more generally an aspect of compatibility >> decomposition, and therefore happens when NFKD is employed. I >> think the text should reflect this. > > How about this? > > OLD Because one aspect of Unicode normalization form KC (NFKC) is > width mapping, a profile that uses NFKC does not need to specify > width mapping. > > NEW Because Unicode normalization form KC (NFKC) performs width > mapping via compatibility decomposition and subsequent > recomposition, a profile that uses NFKC does not need to specify > width mapping. > That actually misses my point. I'd suggest: NEW Since width mapping is performed as a part of compatibility decomposition, a profile employing either normalization form KD (NFKD), or normalization form KC (NFKC) does not need to specify width mapping.
>> Section 4.1.3 right now says: «Use of the Unicode Default Case >> Folding algorithm is RECOMMENDED.» That statement is broader >> than we want it to be. Use of that algorithm is certainly >> recommended, but if and only if case-preservation is not >> desired. > > Correct. > > A minor note: the Unicode specification does not use the term > "Unicode Default Case Folding algorithm", so it seems better to > refer to it as the "Unicode case folding algorithm" (and also to > reference Chapter 5 of the Unicode Standard). > That is untrue. Section 3.13 "Default Case Algorithms" in the Unicode standard refers to this as the "Default Case Folding", always eliding the "algorithm" though. Chapter 5 later makes a reference to "the default case folding algorithm". My instinct would also have been to refer to Chapter 3, rather than Chapter 5. > Thus: > > If case preservation is not desired, it is RECOMMENDED to use the > Unicode case folding algorithm (see Chapter 5 of the Unicode > Standard). > >> Section 7.11 says the category exempts printable 7-bit ASCII >> from other rules. This is untrue. The algorithm does this, >> utilizing the category. > > Good point. How about: > > By applying this PRECIS-specific category, the algorithm specified > under Section 8 exempts most characters in the (printable) ASCII-7 > range from other rules that might be applied during PRECIS > processing, on the assumption that these code points are in such > wide use that disallowing them would be counter-productive. > Purely for stylistic reasons, i.e. being more in line with how other categories are worded, I would suggest: This PRECIS-specific category consists of all printable, non-space characters from the 7-bit ASCII range. By applying this category, the algorithm specified under Section 8 exempts these characters from other rules that might be applied during PRECIS processing, on the assumption that these code points are in such wide use that disallowing them would be counter-productive. _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
