home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / internat / 965 < prev    next >
Encoding:
Internet Message Format  |  1993-01-01  |  9.3 KB

  1. Path: sparky!uunet!not-for-mail
  2. From: avg@rodan.UU.NET (Vadim Antonov)
  3. Newsgroups: comp.std.internat
  4. Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
  5. Date: 1 Jan 1993 04:45:31 -0500
  6. Organization: UUNET Technologies Inc, Falls Church, VA
  7. Lines: 212
  8. Message-ID: <1i13rrINNars@rodan.UU.NET>
  9. References: <8490@charon.cwi.nl> <1hvu79INN4qf@rodan.UU.NET> <1i0oj2INNp4v@life.ai.mit.edu>
  10. NNTP-Posting-Host: rodan.uu.net
  11. Keywords: ISO10646 Unicode
  12.  
  13. In article <1i0oj2INNp4v@life.ai.mit.edu> glenn@wheat-chex.ai.mit.edu (Glenn A. Adams) writes:
  14. >In article <1hvu79INN4qf@rodan.UU.NET> avg@rodan.UU.NET (Vadim Antonov) writes:
  15. >>If a combination of letters is treated as a letter IT IS A LETTER.
  16. >So, are <qu> and <ch> letters in English? 
  17.  
  18. We were talking about lexicographical sorting, not abouth phonetics.
  19. Your argument is irrelevant.
  20.  
  21. >>The idea of visual encoding (and one letter-onr glyph is nothing more
  22. >>than a compressed image of the text) is simply wrong...
  23. >
  24. >Where did you get the idea that 10646 is a "visual encoding"?  Sure
  25. >10646 contains some glyphic like encodings.  But they are there not
  26. >only to satisfy compatibility goals.  Nobody is recommending their
  27. >use. 
  28.  
  29. Isn't it easy to comprehend that ASCII/Unicode/whatever representation
  30. of text is a form of compression of a graphical image from a particular
  31. class of images? I thought everybody who ever bothered to read Shannon
  32. knows it.
  33.  
  34. >>10646 was meant as an encoding eliminating the necessity to carry off-text
  35. >>information (which is not a piece of cake, especially in multi-lingual
  36. >>texts).
  37.  
  38. >This is just complete nonsense.  I don't know who you've been talking
  39. >with, but whoever it was, they certainly don't know much about 10646
  40. >or Unicode.  Unicode (and the 10646 BMP by extension) is oriented around
  41. >encoding the minimum content that allows for minimally legible display.
  42.  
  43. Then you KNOW that it is compressed graphical format -- which is
  44. essentially useless in anything except for storing and then reproduction
  45. of the text.
  46.  
  47. What makes encoded text useful is that its encoding extracts
  48. some SEMANTIC allowing for mechanical processing (particularly sorting).
  49. The semantic in ASCII is hard-coded -- it is the order of letters
  50. and the trivial upper-case to lower-case convertion.
  51. Unfortunately the move to abolish the last traces of semantic and
  52. make it PURELY graphical format destroyed the usefulness of such
  53. encoding for data processing.
  54.  
  55. >This is alredy a well known and understood model for text:  ASCII, EBCDIC,
  56. >etc.   I don't know a single ASCII-only encoding that tells me what
  57. >language it is, what correct sort order to use, what font to display it
  58. >with, etc.
  59.  
  60. ASCII is for English, period.
  61. And as i see the ASCII model is not really "well known and understood",
  62. at least not by my respectable opponent.
  63.  
  64. >Why should Unicode change this?
  65.  
  66. I wonder. It CHANGED some fundamental properties of ASCII -- it
  67. does not have upper-case/lower-case symmetry and ariphmetic order
  68. is no longer equivalent to the lexicographical (and even does not
  69. allow for a trivial comparison algorithm).
  70.  
  71. "Why should Unicode change this?" You should know better.
  72.  
  73. >Nobody (who understands Unicode) ever claimed that it could solve all
  74. >text processing problems without extra information. 
  75.  
  76. Look - if a program has that "extra information" it already know
  77. the small alphabet of a particular language and the deliberate
  78. Unicode stuff is nothing more than wasted bits.
  79.  
  80. >Indeed, Unicode
  81. >explicitly does not specify this additional information for good
  82. >engineering reasons.
  83.  
  84. Now, the complete lack of logic is called "good engineering reasons".
  85.  
  86. >Consider for a moment why this was a good idea:  (1) Unicode fits the
  87. >ASCII model extremely well;
  88.  
  89. Wrong. See before.
  90.  
  91. >(2) Unicode explicitly supports higher
  92. >level protocols just like ASCII, e.g., escape sequences;
  93.  
  94. Ok, though it's nothing more than "there are 32 non-graphic characters".
  95.  
  96. >(3) the
  97. >designers of Unicode recognized that an essentially unbounded amount
  98. >of additional information may be useful for various text processes,
  99. >various system platforms, etc.;
  100.  
  101. And threw out the child together with water.
  102.  
  103. >(4) obtaining a consensus in ISO on
  104. >a universal set of characters is an enormous problem -- expanding the
  105. >goals to solve all the problems of multi-lingual text processing
  106. >would have doomed the effort from the beginning.
  107.  
  108. It has nothing to do with the final product. I saw enough ISO standards
  109. such that we'd all be much better off if they were never accepted.
  110. Note that ASCII is _American_ standard.
  111.  
  112. >Good engineers know that building solutions to complex problems require
  113. >dividing it into simpler sub-problem.  Good engineers also recognize
  114. >that many complex problems do not have a single optimal solution, but many
  115. >sub-optimal solutions.
  116.  
  117. Good engineers usually think before writing standards.
  118.  
  119. >The designers of Unicode and 10646 recognized
  120. >from considerable experience in the field that the biggest problem was
  121. >the proliferation of incomplete, inadequate character sets.  Creating
  122. >a single character set that could correct this rapidly problematic
  123. >state of affairs was the single and most important goal of Unicode's
  124. >design.  Doing this task efficiently and with some measure of compatibility,
  125. >both for existing data and existing software, were also important
  126. >goals for its design.
  127.  
  128. If it was THE goal the set of national standard encodings (which are alredy
  129. in place for decades) is quite adequate. The only action needed was
  130. to assign them "standard numbers" (as in Internet protocols) and to
  131. define minimal subsets.
  132.  
  133. However, the result is nothing more than one more inefficient encoding
  134. leaving all the old problems exactly where they were.
  135.  
  136. >What Unicode was not designed to do is extremely important for you and
  137. >others to know.  It was not designed to solve the "multi-lingual text
  138. >processing" problem. 
  139.  
  140. Hear, hear! Then if it was not designed to do
  141. 1) multi-lingual
  142. 2) text
  143. 3) processing
  144. what the hell it was designed for? Monolingual was around since Morse,
  145. non-text - obviously not the case. Aha! It was not meant to allow
  146. *processing* of text. I'd like everybody to understand that and drop
  147. the hopes on the sensible standard in the future.
  148.  
  149. >Indeed, I would challenge you to create a single
  150. >character set, which, in and of itself, solves this problem,
  151.  
  152. See my previous postings. The idea is trivial as it is and surely
  153. not new.
  154.  
  155. >and which
  156. >could pass through existing standard bodies to become an international
  157. >standard. 
  158.  
  159. Now, we got to the root of the problem.
  160.  
  161. >Your radical optimism about the possibility of doing so
  162. >leads me to believe that you really have little experience in this field.
  163.  
  164. Somehow i had introduced my "own" cyrillic encoding and it lived (and
  165. still lives) and was used by a lot of people (it became obsolete nearly
  166. at the time it was approved as a national standard). The company i worked
  167. before managed to create a totally bilingual family of Unix-like systems --
  168. something unheard of in the West. I was in a leading position in a
  169. company which built the now-largest European e-mail network -- and
  170. it IS 8-bit transparent and bilingual too. I dare to say that i have the
  171. real-life expericence with internationalization issues. Somehow,
  172. people in my company got a different attitude -- they do real things leaving
  173. bureaucracy to bureaucrats.
  174.  
  175. >[Not to say that others, including myself, didn't start out with a similar
  176. >ungrounded optimism.]
  177.  
  178. I always thought that Communist USSR was a stronghold of Kafkaese
  179. bureaucracy. It turns out that the so-called "free world" is much
  180. worse. I'm starting to think about joining the Communist Party :-)
  181.  
  182. >If you want to truly bring forward the state of the art in multi-lingual
  183. >text processing, you would be much better off to consider how to begin
  184. >using Unicode (10646) with all of its intentional, designed-in limitations,
  185. >rather than incorrectly attributing to 10646 a goal of panacea, then using
  186. >the reality  of its limitations to shoot down your misattribution.
  187.  
  188. I'm not going to start using Unicode because i know the underwater
  189. boulders you haven't yet discovered -- exactly because we did the
  190. similar (though limited) things before.
  191.  
  192. >If you
  193. >take the time to look at the facts, you will find that (1) Unicode was
  194. >designed by a truly global community, and not a USCentric one as has been
  195. >wrongly claimed;
  196.  
  197. I don't care who grew an apple if it is good enough.
  198. [Need i to remind that the road to hell is paved with good intentions?]
  199.  
  200. >(2) Unicode and 10646 continues to solicit ideas
  201. >and aid from persons who have useful contributions to make;
  202.  
  203. You got my free advice -- drop the idea of single code per single
  204. glyph and restore the alphabetical ordering. Otherwise the whole
  205. enterprise makes no sense. I'm tired to reiterate the simple
  206. arguments.
  207.  
  208. >and, (3)
  209. >Unicode (10646) provides an adequate foundation on which complete
  210. >solutions to the problems of multi-lingual text processing can be
  211. >constructed.
  212.  
  213. Wrong. See detailed explanation in my previous postings.
  214.  
  215. >If you have a genuine interest in learning about the facts surrounding
  216. >Unicode and 10646, I would recommend a good reading of the Unicode Standard
  217. >and the Proceedings of the Unicode Implementor's Workshops.
  218.  
  219. Thank you, i've got no time to read things i don't need.
  220. I already got my share of meetings in the U.S.S.R. and have sworn to avoid
  221. it like plague. That million lemmings got drowned themselves does
  222. not make me to feel like suicide.
  223.  
  224. --vadim
  225.