home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / std / internat / 1031 < prev    next >
Encoding:
Internet Message Format  |  1993-01-05  |  4.7 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!att!allegra!alice!andrew
  2. From: andrew@alice.att.com (Andrew Hume)
  3. Newsgroups: comp.std.internat
  4. Subject: Re: Data tagging (was: 8-bit representation, plus an X problem)
  5. Message-ID: <24551@alice.att.com>
  6. Date: 5 Jan 93 02:41:49 GMT
  7. Article-I.D.: alice.24551
  8. References: <24426@alice.att.com| <1gpruaINNhfm@frigate.doc.ic.ac.uk> <2606@titccy.cc.titech.ac.jp>
  9. Organization: AT&T Bell Laboratories, Murray Hill NJ
  10. Lines: 97
  11.  
  12. be warned that my comments here are not meant to be belligerent;
  13. i am just trying to figure out the complaints.
  14.  
  15. In article <2606@titccy.cc.titech.ac.jp>, mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
  16. ~ In article <24494@alice.att.com> andrew@alice.att.com (Andrew Hume) writes:
  17. ~ 
  18. ~ >    this is a fundamental and persistent misapprehension of
  19. ~ >10646. it was neither designed for, nor can it allowd a system
  20. ~ >to display identical Han characters (same 10646 codepoint)
  21. ~ >in different fonts WITHOUT some other (non-10646) convention.
  22. ~ 
  23. ~ As it defines the same code point for correnponding Japanese/Chinese
  24. ~ characters, differentiation is impossible.
  25.  
  26.     this is agreeing with me, right?
  27.  
  28. ~ >10646 simply defines codepoints, allowing the unambiguous specification
  29. ~ >of the characters. if you want to set (or switch) fonts, then you
  30. ~ >have to invent some scheme to do it, as say ISO 2022 does
  31. ~ >(in a slightly clumsy way).
  32.  
  33. ~ Then, why you use ISO 10646? Can't we use ISO 2022?
  34.  
  35.     because 2022 is utterly hopeless. in fact, 2022 simply defines
  36. how to interpret byte streams (7 or 8 bit) using special sequences
  37. to load new character sets and to switch between them. to actually know
  38. what characters are meant, you have to know what the special escape
  39. sequences are AND know how that particular small character set works.
  40. furthermore, this is now a stateful encoding, so you can't seek or anything.
  41. just horrible. at least with 10646, i know all teh characters NOW, and there
  42. is no state switching.
  43.  
  44. ~ >    i claim NT has some convention in addition to the locale
  45. ~ >(perhaps, it is part of the lcoale's definition) so it can do this.
  46. ~ >but i don't know.
  47. ~ 
  48. ~ Then, how can I create a text file which contains both Chinese
  49. ~ and Japanese?
  50.  
  51.     i said i didn't know; presumably, there are magic commands (a la RTF)
  52. that change fonts.
  53.  
  54. ~ >> Shouldn't we use error numbers internally and interprete it by local
  55. ~ >> programs?
  56. ~ 
  57. ~ >    when the protocol was updated, this was taken out
  58. ~ >and errors are now just text strings (64 bytes i think).
  59. ~ 
  60. ~ Making everything English text is another fatal misdesign of Plan 9
  61. ~ as an internationalized OS.
  62.  
  63.     damned if i know where i said the text was english. it happens to
  64. be for us for the file server we have for our jukebox. we don't legislate
  65. the language, just that it is 10646 characters (sorry, you can't mix japanes
  66. and chinese within error messages).
  67.  
  68. ~ >    the bottom line is, when you connect to remote services,
  69. ~ >there is simply no way to know what they might report as errors.
  70. ~ 
  71. ~ If you are connecting to some server, you know the protocol you use
  72. ~ in which meanings on error numbers are contained.
  73.  
  74.     just wrong. i attempt to open a file. an error is returned.
  75. the protocol doesn't define nor restrict how that may have failed.
  76. sure we can guess common ones ('file does not exist'); but what about rare
  77. ones ("its bob's file and he's gone home")?
  78.  
  79. ~ >the problem is that a file server, say, may have an arbitrary
  80. ~ >number of error conditions, many of which may not be known locally.
  81. ~ 
  82. ~ Or, how can the client program know the severity of the error? Should
  83. ~ client program retry on error? How many times? Or should the client
  84. ~ abort the current transaction and retry? Or should the client
  85. ~ abort the entire job?
  86.  
  87.     good idea (not that it has anything to do with error numbers)!
  88. by default, we assume that file servers are working or not. but in general,
  89. it would be plausible for the file server to prefix its error message
  90. with a convential token indicating whether or not to retry. again, this
  91. should be a file server depependent thing and therefore cannot be tied
  92. to any particular set of error numbers.
  93.  
  94. ~ Even if the version of the server is updated and new error codes are added,
  95. ~ the server should know the version of the client and return old error code.
  96. ~ Or, how can the client program behave? Of course, for purely
  97. ~ informational purpose only, you can still report it, say, as "unknown
  98. ~ error # 42", which is of no help.
  99.  
  100.     not sure what this means. in any case, returning text avoids any
  101. synchronisation problems.
  102.  
  103.  
  104.     and just in case you were wondering why this is being pursued,
  105. it shows why having international character sets isn't the same as i18n.
  106. you have to deal with things like errno and so on.
  107.  
  108.         andrew hume
  109.