Date: Wed, 14 Oct 1992 09:39:08 CDT
From: "Masataka Ohta" <[log in to unmask]>
> The problem, as I see it, is that many users, including myself, need full
> 10646 (Unicode) systems yesterday. Many more also need it but don't yet
> know this. It's a little like networking. Before TCP/IP became a defacto
> standard after the introduction of BSD4.2 Unix in 1984, many different,
> incompatible systems were built, e.g., Houston SPOOLER, ARPA/NCP, Berknet,
> UUCP, BITNET, and so forth.
While your suggestive analogy between networking and character encoding
is quite interesting, wouldn't it be more acculate to regard
10646 (Unicode) as OSI?
No. I wasn't comparing 10646 to any one of these networking standards; rather,
I was comparing the rise of networking support in general to what I believe
will be the case in the rise of 10646 support.
This is particularly true since 10646 has no competing character set; this
clearly is not the case with TCP/IP vs. OSI where there is a strong
competition. If the merger hadn't occurred between Unicode and 10646, we
probably would have ended up in a similar situation; but since they were
merged, we can thankfully avoid this situation.
> What should the system software do when a program expects A WITH ACUTE to
> be one code element, and not two? Will uses of getc() have to be replaced
> by gets() in order to return more than one code element? Or will getc()
> have to compose sequences into precomposed code elements (but then
> getc() would have to look at all the character code elements, etc.)?
Those well known questions should have been answered before 10646 was
standardized through which 10646 could have been modified to be a much
more usable standard.
These questions *were* addressed prior to 10646 standardization. The
resolution was that TEXT ELEMENTS != CODE ELEMENTS. The problem now is
to evolve text processing software to recognize this new, more general
situation. The correct decision was made with 10646; it will now require
implementors to find the correct implementation solutions.
> Given these problems, I do expect that interim solutions will continue to
> be created.
What we need now is, according to your analogy, TCP/IP.
No. What we need now is two or three implementations from which we can
learn, rather than arguing ex nihilo.