home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / std / internat / 1102 < prev    next >
Encoding:
Internet Message Format  |  1993-01-07  |  3.3 KB
  1. From: arnet@hpcupt1.cup.hp.com (Arne Thormodsen)
  2. Date: Wed, 6 Jan 1993 17:28:17 GMT
  3. Subject: Re: Let's develop ISO sorting rules
  4. Message-ID: <140950002@hpcupt1.cup.hp.com>
  5. Organization: Hewlett Packard, Cupertino
  6. Path: sparky!uunet!spool.mu.edu!sdd.hp.com!hpscit.sc.hp.com!hplextra!hpcss01!hpcupt1!arnet
  7. Newsgroups: comp.std.internat
  8. References: <1ibmdcEINNooe@uni-erlangen.de>
  9. Lines: 67
  10.  
  11. Markus Kuhn writes:
  12.  
  13. >My vision is NOT a sorting order that is embedded in the character set.
  14. >That would be too trivial, of course. The Unicode developpers had good
  15. >reasons to embed one into the code table. No, I have a slightly more clever
  16. >algorithm in mind, that will do 2 passes:
  17. >
  18. >   1. ignore punctuations etc. and group letters together before
  19. >      comparing the strings.
  20. >
  21. >   2. No. 1 will not offer a total order, which should be supplied by a
  22. >      beautiful sorting standard. So if 1 fails than compare the strings
  23. >      completely without throwing any trivial information away. Rule 2 must not
  24. >      conflict with rule 1, the partial ordering must only be completed.
  25. >
  26. >I am playing around with an algorithm that works this way since a few
  27. >days, and the results are very promising and easy to understand intuitively.
  28. :
  29. :
  30. >The method deals fine with punctuations in the strings (e.g. in
  31. >bibliographic references and person names), is pretty efficient and
  32. >easy to implement. Word lists produced by my algorithm are pretty easy
  33. >to scan for human eyes. The solution is much more general than simple
  34. >upcase conversion before lexicographic character code comparison which
  35. >is often used today with US-ASCII.
  36. >
  37. >I still don't know, whether I should post the algorithm here, or whether
  38. >I should write a paper or techreport first, as it is much more promising
  39. >than all character code based lexical orderings that have been proposed here
  40. >so far.
  41.  
  42. Markus,
  43.  
  44.    I must admit severe scepticism here, but I am sincerely interested
  45. in what you are doing.  Please post details if you feel you can.
  46.  
  47.    My scepticism is basically this:  I guess you have probably come up
  48. with a method which you believe is more-or-less acceptable to Europeans
  49. and North/South Americans.  What about Chinese, Japanese, Korean,
  50. Hebrew, Arabic, all the Indic languages, Thai, etc?  These are all
  51. commercially important markets, and they have very different sorting
  52. requirements.  Some things you mention, like ignoring "punctuation",
  53. simply won't work for some languages.  For example, in Japanese there
  54. are "punctuation" marks like the "ditto" mark (which means duplicate the
  55. last Kanji) or the Katakana "dash" (which means extend the previous
  56. vowel).  These (should) affect collations.  I am sure there are dozens,
  57. if not hundreds, of similar cases.
  58.  
  59.   Personally (and professionally :-) I believe that the support of
  60. multiple and complex collation algorithms is a necessary and permanent
  61. feature of internationalized programs.  This problem cannot be wished away.
  62.  
  63.   For *internal* purposes (B-trees, etc) a simple sort based on numeric
  64. character codes (8, 16 or whatever bits) will always work, and is the
  65. fastest method possible.
  66.  
  67.   I don't see a market need for the kind of "in-between" solution you
  68. are proposing (but I am still interested...)
  69.  
  70. --arne
  71.  
  72. Arne Thormodsen
  73. CSO Internationalization
  74. Hewlett-Packard
  75.  
  76. DISCLAIMER:  These views are my own and do not necessarily represent
  77. any views of the Hewlett-Packard Company.
  78.