Subject: Re: [idn] Dots, and a path to working IDNs

From: [email-masked]
Date: Fri, 1 Jun 2001 12:56:59 -0700

Hello, 
I have been speaking about the way to put characters
inside an operating system since 1990.  It has been ignored.
So, we keep getting crashes from character input
modules, as well as Japanese handheld wireless 
devices.  But I consider this is a necessary step for
people to try out alternatives.  No harm at all!  

And please note:
There is no requirement or necessity for everybody to 
change!

But the impack for using such an encoding will evolutionize
Chinese software engineering.  Please read my
article "A user oriented virtual encoding for characters and
 icons can cause a prominent Leap in Chinese Software
 Design" in  Chinese Information Processing, Feb. 1997.
Sorry, it is only in Chinese.

In case anyone cares:  "A language oriented Chinese 
Encoding for multilingual computing environments" 
is published in English, in Proceedings of the 1995
 International  Conference on Computer Processing 
of Oriental Languages, Page 323. 

Liana Ye

On Fri, 1 Jun 2001 11:07:00 -0700 (PDT) "Sean X. Zhang"
<[email-masked]> writes:
> --- [email-masked] wrote:
> > 
> > 
> > On Fri, 1 Jun 2001 02:55:34 +0000 "Adam M. Costello"
> > <[email-masked]> writes:
> > > [email-masked] wrote:
> > > 
> > > > Allow me to comment on your UTF-8 as a long term solution.
> > > 
> > > If I understand correctly, you are proposing an alternative 
> model 
> > > for
> > > representing characters.  Currently, characters are represented 
> as
> > > indices into a table.  If a character is not in the table, it 
> cannot 
> > > be
> > > represented.
> > > 
> > > You are proposing that instead of a table of characters, we have 
> a
> > > table of character-building-blocks, and to represent characters 
> as
> > > instructions for how to compose them from the building blocks.  
> This
> > > would allow new/obscure characters to be used without deploying 
> new
> > > fonts everywhere.
> > > 
> > > (You also propose to represent the building blocks phonetically 
> > > using
> > > ASCII, but I think that's an orthogonal issue.)
> > > 
> > > Is my understanding roughly correct?
> > >
> > 
> > Yes.
> >  
> 
> This is indeed an interesting idea and has been discussed numerous 
> times
> in other forums. To "represent" characters as described above would 
> have 
> to introduce fundamental changes to all applications and all 
> operating
> systems utilizing the characters. That's what ISO-10646 and Unicode 
> are about. I'd prefer to work within the constraint of existing 
> encoding
> mechanisms. I may be wrong, but I don't think this list is the most 
> appropriate forum for introducing these changes. 
> 
> Sean X. Zhang
> 
> >  
> > > It's an interesting idea, but dramatically different from the 
> > > current
> > > text model.  I suspect that you'd have to change lots of things 
> in 
> > > all
> > > applications and all operating systems to make this work.
> > > 
> 
> ....
> 
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail - only $35 
> a year!  http://personal.mail.yahoo.com/

---

From: [email-masked]
Date: Fri, 1 Jun 2001 12:57:46 -0700

John,
 Thanks for a great explaination.  I'd like everybody 
read it, and I'd like this language be in our final draft, and 
proposing it  to WIPO for their WHOIS database 
solution specified in their RFC-3.

Liana Ye

On Fri, 01 Jun 2001 09:55:01 -0400 John C Klensin <[email-masked]>
writes:
> Liana,
> 
> Thanks for taking the time to explain what you are trying to do.
> I hope I understand it now.  The comments below are based on my
> current understanding -- if I have gotten it wrong, please try
> to keep explaining.
> 
> --On Thursday, 31 May, 2001 23:40 -0700 [email-masked]
> wrote:
> 
> >...
> >> (You also propose to represent the building blocks
> >> phonetically  using
> >...
> >> Regarding the use of English keyboards, I'm not sure what
> >> your point  is.
> >> The representation of text in a file or on a wire is
> >> unrelated to  how
> >> users type that text, right?
> >> 
> > Not quite, but good catch. It is depending on which operating 
> > model you are asuming.  But that is another subject.
> 
> _If_ I correctly understand this, you will quickly run into the
> problem that many languages contain words that are pronounced
> the same way but spelled differently and words that are spelled
> the same way but pronounced differently.  As long as the DNS is
> essentially/historically text-based, overlaying a phonetic
> system on it is a problem for those languages and words (i.e.,
> the mappings are not unique).
> 
> Worse, it is not clear that one can establish a set of
> conventions for representations of characters that work across
> scripts.  From very young ages, people get used to variations on
> ways to print or write characters in their own languages
> (scripts) but not in others: some variations in characters
> derived from the Roman alphabet that are considered "font
> details" would be sufficient to cause "different character" in
> other scripts.  Indeed, as has been suggested in other contexts,
> the glyphs for "i" and "j" may represent the same character or
> not depending on whether the particular language treats them as
> distinct; a different language may have different rules using
> the same script.
> 
> Similar problems presumably apply with phonetic representations.
> The international phonetic alphabet (see the 164ff in the
> Unicode 3.0 book) has changed, and presumably improved, since I
> learned how to use it 40-odd years ago. But I recall its being
> considered "good enough", rather than "exact", and that the
> phonetic community does not believe that a better system exists
> or that a significantly better one is possible across language
> groups.
> 
> Switching from a script-and-text-based model to a character-form
> or phonetic one consequently exchanges one set of problems for
> another, rather than reducing, IMO, the total number of problems.
> 
> But I think the most serious problem, as Adam suggests, is just
> compatibility between systems: a mix of the two is probably
> worse than either by itself.
> 
> That said, one might think of either phonetic or character-shape
> schemes as candidates for a "layer 3" search system as outlined
> in my "DNS search" discussion (draft-klensin-dns-search-00.txt).
> If one could use such systems as a means of input which would
> then go through a software process of both searching (not
> exact-match DNS lookups) databases for possible matches and,
> where necessary, dialogue with the users, they might become very
> strong candidates, especially where the users were not easily
> able to put more direct representations of the characters in
> from keyboards.
> 
>    john
>