From ALB%SEAS@liverpool.ac.uk Tue Jan 7 01:40:29 1992 Received: from danpost2.uni-c.dk by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA24747; Tue, 7 Jan 92 01:40:29 +0100 Received: from vm.uni-c.dk by danpost2.uni-c.dk (5.65/1.34) id AA27088; Tue, 7 Jan 92 00:40:12 GMT Message-Id: <9201070040.AA27088@danpost2.uni-c.dk> Received: from vm.uni-c.dk by vm.uni-c.dk (IBM VM SMTP V2R1) with BSMTP id 1774; Tue, 07 Jan 92 01:40:34 DNT Received: from UKACRL.BITNET by vm.uni-c.dk (Mailer R2.07) with BSMTP id 5667; Tue, 07 Jan 92 01:40:34 DNT Received: from RL.IB by UKACRL.BITNET (Mailer R2.07) with BSMTP id 0958; Tue, 07 Jan 92 00:39:45 GMT Received: from RL.IB by UK.AC.RL.IB (Mailer R2.07) with BSMTP id 6446; Tue, 07 Jan 92 00:39:45 GMT Via: UK.AC.LIV.IBM; 7 JAN 92 0:39:41 GMT Received: from ALB@SEAS by MAILER(4.1.a); 7 Jan 1992 00:41:25 GM Addressed-To: I18N@EARN.DK.DKUUG Via MAILER Addressed-From: ALAIN_LA_BONTE (Alain LaBonte O1 418 644 1835) Subject: Short character ids are "passwords" of internationalization Date: Tue, 7 Jan 1992 00:33 GMT To: I18N@DKUUG.DK From: ALB X-Charset: ASCII X-Char-Esc: 29 :From: dan@com.ibm.watson (Walt Daniels) : :>If o/ denotes o-with-stroke I could write: :> :> if (c == '\') .... :>Keld :That looks like a perfectly legal character string without any :mneumonic interpretation. How do you distinguish? I presume you add :a new character to those whose escaping has a special significance, but :it is certainly not a compatible change. This is but one application. Of course it requires sender and recipient multual agreement on the delimiter. If I understand correctly, the mnemonics does not automatically include the "<" and ">" pair (or correct me if I am wrong): these are the default symbolic delimiters. The issue is that there are character identifiers (their names) which are: 1) much too long (some exceed a screen width of 80 characters to express a single graphic character); 2) an unique id (ideally, short, mnemonic, with no linguistic bias) using the portable character set only is required to transfer meaning of characters everywhere (even here on this network), whatever the coding. Unless we use the universal character set itself (which is not possible here for example, character meaning must be preserved, and as economically as possible - why use 82 characters to describe a single Greek character for example). If there are other ways, they remain to be found. If there is no other, then to negate such a process is negating a need to which there is a simple and straightforward solution. :Besides which the "trend" is supposed to be to write internationalized :programs, instead of localized programs. One of the rules of :internationalized programs is that literal strings must be in message :catalogs or some such. What if the message catalog is in the universal character set and it must be ported to EBCIC 037 CECP? to IBM code page 850? to IBM code page 437? to ISO 646 (which has no more than 94 characters)? to HP Roman-8? How do you preserve data integrity, with no proprietary architectured software? Who defines the conventions? ISO I guess and this is a really simple convention, which does not mean the program is localized. It is built to preserve data integrity, given the constraints of unknown features of undetermined environments. An internationalized program is a program that adapts without fault to the country where it is implemented, not an old program we don't want to change and that is accommodated by loose standards that only force all country's acceptance of narrow designs of the past. Now this is of course easier to say than to realize. But I think this leads us to also deal with the past without jeopardizing the future's ability to be more state-of-the art-oriented. Alain LaBont