Re: tlug: recommendable email software]

[NIIBE Yutaka <gniibe@example.com>]

Hello Stephan, thank you for your attention.

Stephen J. Turnbull writes:
 > I just want to add that I understand that Niibe-san is not talking
 > about using Unicode himself; I am pointing to the amount of resources
 > behind Unicode and the lack of tools for it even now, and saying that
 > I think that the much more general approach Niibe-san is advocating
 > will also require a lot of work; perhaps more than implementing
 > Unicode tools.

Yes, sure.  I (<-- this means that there is no consensus even our
group ;-) think that because it requires much work to get real
multi-lingualization of computing environment, it's not good/worth to
split human resources into Unicode supporter, Anti-Unicode group,
ISO-2022 supporter, etc., etc.  Why don't we co-operate togerther?

I hope that we can offer powerful mechanism so that many efforts
(Unicode, ISO-2022, JIS, Big-5, Shift-JIS, whatever the policy is) can
be implement on top of it.  Currently our focus is on "CHARACTER".

Personally speaking, the Unicode 2.0 book is quite good, at least for
survey around m17n (please note that I don't refer specific
implementation of Unicode).  However, unfortunately for m17n, saying
"Unicode does not mean bad", many Japanese get mad. ;-)  So, I don't
say that to avoid being labelled "Unicoder".

			*	*	*

So far, MULE offers powerful machanism for encoded texts.  Let's think
about Japanese environment.  You know, there are three major encoding
for Japanese text, i.e. ISO-2022-JP, Shift JIS, and EUC.  While some
users like Shift JIS for there operating system, some protocol require
ISO-2022-JP.  There were political wars "which is best?"  The idea of
"MULE" began in such a situation, and its approach is "offer powerful
mechanism that can support ALL of them".  We didn't decide which
encoding is best, because there exist three encoding already in the
real world.  We think that it's up to user who decide it.  Then, many
problems around "ENCODING" has been solved (and left untouched :-)
with MULE, I believe.

However, implementation of MULE is, say, ISO-2022-based.  In other
words, it is based on coded character sets.  I think that although it
was good design choice for old environment with limited resources,
coded-character-set-oriented approach is not best one for m17n.  We
need some more powerful mechanism for handling _characters_.

With current implementation of MULE (or whatever application is),
character is defined as the member of character set.  That's
character-set-oriented approach (we called), but it is not natural
definition.  It's better if we can handle character itself more
naturally, and define any character sets from characters users
specified.  For example, don't label character 'A' as member of ASCII,
but define like:

      Character 'A':
         First character of latin script
	 65th element of ASCII
	 (3, 65) in JIS X 0208
	 ...

With those handling of text with "character oriented apporoach", it's
more interoperable with existing environment.  Good example is display
Unicode encoded text with existing font sets encoded ISO 2022 scheme.

			*	*	*

 > But we'll see how it works out; the time-table is also quite
 > ambitious, a prototype text-handling layer with Mule built on top of
 > it---in 6 months.  Wow!

Don't expect too much. :-)

Quick release, distribute often to share the technology, even if
it's not mature.  We don't think that our approach is ultimate one.
Surely, there will be many improvements along with the feedback.  More
important ideas will spawn by someone.  That's our pleasure.

Enjoy, 
-- 
NIIBE Yutaka
---------------------------------------------------------------
Next TLUG Meeting: 11 April Sat, Tokyo Station Yaesu gate 12:30
Featuring Tague Griffith of Netscape i18n talking on source code
---------------------------------------------------------------
a word from the sponsor:
TWICS - Japan's First Public-Access Internet System
www.twics.com  info@example.com  Tel:03-3351-5977  Fax:03-3353-6096