Since the discussion is long and complex, I'm making a summary of current discussions. I try short, accurate, and not-misleading, please point out if I'm not doing well. John is making 3 different arguments in parallel: 1. Tr in UTR#50 has technical issues. This should go to Unicode, not www-style. 2. Tr impl costs is not worth to its value. Accepted. CSS now allows tailoring by re-defining Tr as U. The diff by this change is subtle. 3. CSS should prohibit impl of Tr as defined in UTR#50 for consistency and simplicity. Disagreed, 1) we should allow any Unicode-compliant impl as CSS-compliant, 2) we acknowledged the diff is subtle in #2, and 3) UTR#50 impl is simpler under different architecture. Some members of UTC requested that CSS should allow any Unicode-compliant impl as CSS-compliant. Sylvain said as a matter of principle we should avoid optional behavior. James Clark said, for the same reason as John's #3 and Sylvain, CSS should only allow UTR#50-compliant impl and disallow tailoring. My preference is to allow both UTR#50 and the tailoring in John's #2. CSS already allows a lot of tailoring, such as Turkish uppercasing or UAX#14 grapheme cluster. As a secondary preference, if tailoring is really bad and that subtle consistency is critical, I'd agree with James. I18N WG puts this topic on its agenda next week, I hope this clarifies the whole discussions and each position for I18N WG to discuss, and anyone else to jump in if s/he wants to. /kojiReceived on Saturday, 28 September 2013 11:30:10 UTC
This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:32 UTC