[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] opting out of SC/TC equivalence
Hi Liana
----- Original Message -----
From: <liana.ydisg@juno.com>
To: <harald@alvestrand.no>
Cc: <liana.ydisg@juno.com>; <tsenglm@cc.ncu.edu.tw>; <huangk@alum.sinica.edu>; <idn@ops.ietf.org>
Sent: Thursday, August 30, 2001 9:17 AM
Subject: Re: [idn] opting out of SC/TC equivalence
> That is not the case. If IETF does not want to put TC/SC
> folding in [nameprep], then it has no good reason to
> agree a versioning table to include GB, Big5, KSC, JIS to
> transliterated ACE map. In that case, I am no motivation
> to push for Unicode to accept the long list of radicals.
> I can sit back and see how long this will go, as I have been
> assumed that by now the TC/SC should have been in there
> long time ago, which has been proved by James that I
> was wrong.
>
> As this point, I think a little more Han radical classification
> background infor is helpful. The Han radical has about
> a dozen dictionary editor's classifications, which is the radicals
> included in UCS. There are about a multitude of hundreds
> of programmers' viewpoints on this. The one I am in favor of
> and have been implemented by quite a few good encoding
> software are all AI and phonetic based approach, which is used
> by common people when they communicate specific characters
> mostly used in names. Similar in the way, English speakers
> say "D as it's in Dog." Studys in the late 80's have been shown
> there are about 1000 -1200 such radicals conventionally not
> considered as radicals. Since RADICAL in Chinese often
> means the indexing group in a dictionary, and only takes
> one radical per character. So radical set in this sense is not
> the complete listing of radicals in Han. So it is not complete list
> for SC radicals, neither the UCS has a complete list for the
> same reason.
>
> If IETF has no architecture to accomodate these types
> of script requirement, and is not planning to use a complete
> list of radicals, please give me a reason for me to push it for
> Unicode standard.
I remember that someone in IETF suggest to provide an architecture
to accomodate these requirement. to handle codepoint is not the task
and superority of IETF, but we in IETF should define the architecture
and leave the interface for other consortium to deal with that. If
all consortium just push it to others without enough efforts, there
may be deadlock to implement it.
>
> Another option is that IETF still can go ahead giving the world a
> simple listing of 4128 TC/SC equivalent listing some where
> else, catching up with your product delivering schedule, waiving
> hands and say: take care of it, but out of my sight. The end result
> is just like Unicode imposing a misconception of TC/SC are
> two different languges. I hope my explaination can shed a little
> light on CNNIC's feeling about TC/SC arguements. You also
> can tell me that my input is out of the scope of this group, and
> I am ready to leave too.
I agree with you. :)
>
> Liana
>
>
> On Wed, 29 Aug 2001 22:58:08 +0200 Harald Tveit Alvestrand
> <harald@alvestrand.no> writes:
> >
> >
> > --On 29. august 2001 10:59 -0700 liana.ydisg@juno.com wrote:
> >
> > >
> > > That is the reason I propose to increase radical section in
> > > Unicode to cover 1000 radicals, and for WG to agree a versioning
> > > table to include GB, Big5, KSC, JIS to transliterated ACE map.
> >
> > OK, so this proposal cannot be acted on by the IETF until the
> > proposal for
> > additional radicals in Unicode has been accepted.
> >
> > Then I think it is not a possible solution at the timescale when
> > this group
> > is planning to deliver a product.
> >
> > Thank you for the clarification.
> >
> > Harald
> >
> >
>