No, that wouldn't do as you intend. The kTraditionalVariant is not a normative field; it was originally based on an algorithmic comparison of, as it happens, GB 2812 to GB 12345; while it has improved over time, I would not put any real weight on it without a thorough review.
Mark ————— Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr] http://www.macchiato.com ----- Original Message ----- From: "Adam M. Costello" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, January 28, 2002 18:06 Subject: Re: [idn] Re: peanut gallery > Mark Davis <[EMAIL PROTECTED]> wrote: > > > The 'prohibit Simplified Chinese code points', even from a purely > > technical point of view, is a bad idea. Trying to do it by just > > algorithmically comparing SC/TC standards (e.g. GB 2812 to GB 12345) > > based on mapping tables will give the wrong answer. > > Maybe so, but the goal of the proposal was not to settle the question > of exactly which characters are simplified and which are traditional, > the goal was to prohibit some code points that have no use outside the > Chinese community in order to leave the door open for partial TC/SC > folding in nameprep. (We know that nameprep could never be capable of > full TC/SC folding.) > > (And let say again that I favor IDNA as proposed. This is just a backup > proposal in case a compromise is needed. I hope it's not.) > > Here's a more precise version of the proposal: Prohibit a Han code > point iff it has a kTraditionalVariant and has only "G" sources > (China/Singapore). Would that do what I intend? The list of such code > points could be generated from Unihan.txt by a small awk script. > > AMC > >
