From ALB%SEAS@liverpool.ac.uk Fri Nov 29 18:41:25 1991 Received: from danpost2.uni-c.dk by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA00992; Fri, 29 Nov 91 18:41:25 +0100 Received: from vm.uni-c.dk by danpost2.uni-c.dk (5.65/1.34) id AA20606; Fri, 29 Nov 91 17:41:31 GMT Message-Id: <9111291741.AA20606@danpost2.uni-c.dk> Received: from vm.uni-c.dk by vm.uni-c.dk (IBM VM SMTP V2R1) with BSMTP id 0715; Fri, 29 Nov 91 18:41:20 DNT Received: from UKACRL.BITNET by vm.uni-c.dk (Mailer R2.07) with BSMTP id 2443; Fri, 29 Nov 91 18:41:18 DNT Received: from RL.IB by UKACRL.BITNET (Mailer R2.07) with BSMTP id 1301; Fri, 29 Nov 91 16:11:55 GMT Received: from RL.IB by UK.AC.RL.IB (Mailer R2.07) with BSMTP id 6955; Fri, 29 Nov 91 16:11:54 GMT Via: UK.AC.LIV.IBM; 29 NOV 91 16:11:50 GMT Received: from ALB@SEAS by MAILER(4.1.a); 29 Nov 1991 16:12:26 GM Addressed-To: SC22WG15RIN@EARN.DK.DKUUG Via MAILER Addressed-From: ALAIN_LA_BONTE (Alain LaBonte O1 418 644 1835) Forwarding: Contents of another mailfile... Subject: Comments from Alain LaBont/e on RIN questionnaire Date: Fri, 29 Nov 1991 16:11 GMT To: SC22WG15RIN@DKUUG.DK From: ALB X-Charset: ASCII X-Char-Esc: 29 ---------------------- Forwarded Mail Follows ---------------------- To: SC22WG20@EARN.DK.DKUUG Via MAILER From: ALAIN_LA_BONTE (Alain LaBonte O1 418 644 1835) Subject: Comments on the RIN Questionnaire from Alain LaBont/e Date: Fri, 29 Nov 1991 16:02 GMT Comments of Alain LaBont/e on the RIN questionaire. General comment: in all examples given, involved international standards are rarely listed (ex.: dates in for YYYY-MM-DD, commas of the Internatioanl System of unit as decimal delimiters and spaces as triad separators are not used). I think either the number of examples should be more limited or the involved IS be given as examples). Another concern also is that to answer the questionnaire English must be mastered which might not be the case for vernacular cultures. But I think what we want to know here is just that because great cultures are fairly known and documented already. :7 hours west of GMT, with one hour for summer time on the first :Sunday of April, ending on the last Sunday of October, both at :0200. Names MST and MDT. In certain coutries (multilingual) time zone names are multiple, such as in Canada: EST in English and HNE in French. Make sure it is clear that this can be answered in the questionnaire. :Character sets can be classified into the following classes: : Upper Case : Lower Case : Numeric : Punctuation : White space (characters that just move the print position) : (Plus several that are primarily for computer usage). Here you are suggesting answers according to the POSIX model (this is not wrong but not complete). Letters can also be classified according to families (all the As, accented or not, and so on), Han characters can also be grouped (simplified, variants and so on). What do we really want to achieve here? What is suggested after talks about fallback of character conversion for accented letters, but there is a loss of information in that process that makes information technology unacceptable for a lot of people. Then the affirmations are also biased there (for non computer techies). :- The specification of a collation order different from that : which occurs naturally in the computer character set. : (French and Canadian French use the same character codes, but : collate in different orders.) Here I must strongly protest. French Canadians collate in exactly the same order as the French do. The dictionary order has been inherited from Franco-French French dictionaries... Who vehicles such wrong and highly biased information? If the Canadian standard is refered in this affirmation, it has been built in narrow collaboration with French Frenchpersons of very different middles. : - Certain characters should collate equally even if they are :different characters. (E.g. in some languages the accented : vowels are all equal and the accents do not participate in : collation decisions.) In other words what you say here (and the same is true for the preceding affirmation that some characters are ignored) that collation does not collate. Such an affirmation should be qualified saying they are not considered except in case of equality, in which case a difference must be considered to make the results consistent. :Certain characters should collate as if they were two characters : (Eszet in German, the ae diphthong.) Here again the equivalences must be resolved... :Collation can be done either with upper and lowercase characters :distinct, I doubt this can be acceptable in any culture. Why suggest that which is wrong and leads to confusing results. Would anybody accept this: Abc Abe Abf ... 20 pages ... abc abdz ... 10 pages ... abe abf Only techies can seriously believe this is acceptable... :- Collation order for large character sets (e.g. Asian) can be : specified by ranges of character codes. Here also this can leads to inconsistent results and should be resolved. Order should always be the same... :Possible :issue: Some countries use Hindi digits. Are there other digit :systems :in use that would ever be used in portable computer programs? Some countries also use 2 sytems: the Chinese use Chinese and Arabic digits at the same time. Some countries using a script use different digits as some other countries using the same script (ex.: Egypt uses Hindi digits in Arabic while Morocco uses Arabic digits in Arabic with about no knowledge of Hindi digits for people on the street). I am not sure I understand the purpose of limited examples. :The :representation :of numbers as words is an issue: are there situations :where :in :your culture you would represent a number as words differently :than :a similar culture which uses the same numeric representation and :or :language? (An example is the difference between the British and :American meaning of "billion".) You should specify "a culture" using the same language. Of course words are generally not the same between different languages (ex.: "seventy" in English but "soixante-dix" in French (but also "septante" in Belgian and Swiss French) :Often, :the solution is to have several different character sets, and to :explicitly :switch between them. However, this makes programming more :difficult. Here it is highly biased. There would be a way to store character strings absolutely independently of external coding, in a processable form, taht could be restituted using all kinds of coding. 10646 is not in processable form but is an excellent solution for input and output. The suggestion that it is not practical is highly biased. The other suggestion on the solution is even more biased because it does not appear to me to be the ultimate solution. There are much simpler solutions than such a switching. ------------------------------ Alain LaBont/e Minist\ere des Communications du Qu/ebec