home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / std / internat / 1068 < prev    next >
Encoding:
Internet Message Format  |  1993-01-06  |  3.7 KB
  1. Path: sparky!uunet!wupost!darwin.sura.net!sgiblab!nec-gw!nec-tyo!wnoc-tyo-news!cs.titech!titccy.cc.titech!necom830!mohta
  2. From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
  3. Newsgroups: comp.std.internat
  4. Subject: Re: Data tagging (was: 8-bit representation, plus an X problem)
  5. Message-ID: <2630@titccy.cc.titech.ac.jp>
  6. Date: 6 Jan 93 20:12:23 GMT
  7. References: <24426@alice.att.com| <1gpruaINNhfm@frigate.doc.ic.ac.uk> <2606@titccy.cc.titech.ac.jp> <24551@alice.att.com>
  8. Sender: news@titccy.cc.titech.ac.jp
  9. Organization: Tokyo Institute of Technology
  10. Lines: 86
  11.  
  12. In article <24551@alice.att.com> andrew@alice.att.com (Andrew Hume) writes:
  13.  
  14. >~ Then, why you use ISO 10646? Can't we use ISO 2022?
  15.  
  16. >to actually know
  17. >what characters are meant, you have to know what the special escape
  18. >sequences are AND know how that particular small character set works.
  19. >furthermore, this is now a stateful encoding, so you can't seek or anything.
  20. >just horrible. at least with 10646, i know all teh characters NOW, and there
  21. >is no state switching.
  22.  
  23. Very good.
  24.  
  25. >~ Then, how can I create a text file which contains both Chinese
  26. >~ and Japanese?
  27. >
  28. >    i said i didn't know; presumably, there are magic commands (a la RTF)
  29. >that change fonts.
  30.  
  31. Very good.
  32.  
  33. Then, isn't the magic commands a special escape sequence or something
  34. like that?
  35.  
  36. Mustn't we know how that particular font specification works?
  37.  
  38. Doesn't the font specification make everuthing stateful, so we can't
  39. seek or anything?
  40.  
  41. According to your criteria, 10646 is just horrible and utterly hopeless
  42. to us Japanes.
  43.  
  44. Thus, 10646 can't be a internationally usable standard.
  45.  
  46. >~ Making everything English text is another fatal misdesign of Plan 9
  47. >~ as an internationalized OS.
  48. >
  49. >    damned if i know where i said the text was english.
  50.  
  51. How damned Plan9 is. It is much better to be said "Not a tty" than
  52. "iwmczal aslkdjf lskjancm aslkio" on inappropriate ioctl.
  53.  
  54. >~ If you are connecting to some server, you know the protocol you use
  55. >~ in which meanings on error numbers are contained.
  56. >
  57. >    just wrong. i attempt to open a file. an error is returned.
  58. >the protocol doesn't define nor restrict how that may have failed.
  59. >sure we can guess common ones ('file does not exist'); but what about rare
  60. >ones ("its bob's file and he's gone home")?
  61.  
  62. How can damned you think the state 'file does not exist' is represented
  63. in English?
  64.  
  65. >~ >the problem is that a file server, say, may have an arbitrary
  66. >~ >number of error conditions, many of which may not be known locally.
  67.  
  68. >~ Or, how can the client program know the severity of the error? Should
  69. >~ client program retry on error? How many times? Or should the client
  70. >~ abort the current transaction and retry? Or should the client
  71. >~ abort the entire job?
  72.  
  73. >    good idea (not that it has anything to do with error numbers)!
  74. >by default, we assume that file servers are working or not. but in general,
  75. >it would be plausible for the file server to prefix its error message
  76. >with a convential token indicating whether or not to retry.
  77.  
  78. The problem is that a file server, say, may have an arbitrary number
  79. of its own convential error conditions, many of which may not be
  80. represented by a convential token known locally.
  81.  
  82. >again, this
  83. >should be a file server depependent thing and therefore cannot be tied
  84. >to any particular set of error numbers.
  85.  
  86. Of course, this
  87. should be a file server depependent thing and therefore cannot be tied
  88. to any particular set of convential tokens.
  89.  
  90. >    and just in case you were wondering why this is being pursued,
  91. >it shows why having international character sets isn't the same as i18n.
  92. >you have to deal with things like errno and so on.
  93.  
  94. Internationalization of "errno" interpretation is a simple and
  95. already-solved problem.
  96.  
  97.                         Masataka Ohta
  98.