Joel Rees responded:
> > > If UNICODE can never attempt to address the issue of non-closure,
> >
> > You've got it completely backwards. The Unicode Standard is the one
> > with the open repertoire, which is why it keeps expanding year to year.
>
> I know you can't foresee breaking past 17 planes, but remember that ten
> years ago it was still a little hard to imagine GB hard drives being on
> everyone's desktops. Shoot. My freshman year we were glad to get a little
> piece of the college's brand-new 100M drive for our basic programs.
Moore's Law has applied, with slight fudge factors, since 1965 to *hardware* --
memory chip performance primarily, but also CPU speed, hard drive size, and so
forth. (By the way, it is a 45-GB hard drive on my desktop, as the
hardware marches on!)
Moore's Law does *not* apply to character encoding. See my post on the
velocity of character encoding in Unicode, which shows (other than the
recent Han anomaly), a logarithmic decay of the encoding velocity, based
on 11 years of historical data for the Unicode Standard.
> I balked
> at the idea of needing more than 16 bits to address both program and data.
> I'm telling you that 17 planes is not enough, and it _will_ become a painful
> constraint in your lifetime.
And I'm telling you they're aren't enough standardizers with enough hours
in the day to *make* it a problem in my lifetime. And that is based on
having sat in the relevant character standardizing committes for the Unicode
Standard for eleven years now.
> Maybe I'm a crackpot, but the need is there and people will use and abuse
> UNICODE in ways that you probably don't want to imagine.
Well, I've got no complaint with that claim. They already do. ;-)
> What I'm trying to
> push is building the mechanism now for dodging most of the abuse.
And I'm claiming that the Unicode Standard doesn't need any more
code extension mechanisms. It is engineered to the right size now
to last for as long as it needs to, without futzing further with
the encoding architecture per se.
--Ken
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:21:19 EDT