From asmusf@microsoft.com Fri Feb 25 04:19:11 1994 Received: from netmail2.microsoft.com by dkuug.dk with SMTP id AA08432 (5.65c8/IDA-1.4.4j for ); Fri, 25 Feb 1994 21:21:05 +0100 Received: by netmail2.microsoft.com (5.65/25-eef) id AA28904; Fri, 25 Feb 94 12:21:38 -0800 Message-Id: <9402252021.AA28904@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Fri, 25 Feb 94 12:21:38 PST X-Msmail-Message-Id: 452D84F3 X-Msmail-Conversation-Id: 452D84F3 From: Asmus Freytag To: i18n@dkuug.dk, iso10646@jhuvm.hcf.jhu.edu, SC22WG20-request@dkuug.dk, rtfq-forum@crim.ca, sc22wg20@dkuug.dk, tc304@dkuug.dk Date: Fri, 25 Feb 94 12:19:11 PST Subject: RE: (SC22WG20.866) Multiscript Ordering -- Survey on a fundamental issue Cc: bealle@torolab6.vnet.ibm.com, cpwg-mail@revcan.rct.ca, umavs@torolab6.vnet.ibm.com X-Charset: ASCII X-Char-Esc: 29 Let's settle this not by preference, but by customer requirement. Last August I visited the data architects for one of the largest computer installations world-wide that operates on more than one script. In fact their near term requirements are support of 3 scripts. They were quite clear about their requirement to have any field in their databases contain (possibly) a mixture of all 3 scripts. If a new standard is to be useful, it has to address this case w/o restrictions. Anything else is pretty much wasted time. A./ ---------- | From: | To: ; ; ; | ; | Cc: ; ; | | Subject: (SC22WG20.866) Multiscript Ordering -- Survey on a fundamental issue | Date: Friday, February 25, 1994 5:32PM | | | ---------- | I would like to have as many people state their preference on the following: | | 1) Is it acceptable, in an eventual international standard on multiscript | ordering, to constrain applications to separate different scripts | (ex.: Latin, Greek, Cyrillic, Han, Thai, Arabic, Hebrew, and so on) into | different fields to be compared, so that only one script set would be | processed at a time? | | 2) Is it necessary to have no restrictions at all and that any given field | contain characters from different scripts, given that, anyway, script | tables will not be intermixed? (nuance: if one wishes, different scripts | could be intermixed, and considered one script for a given application, | with the envisaged tailorability feature; this should be considered a | special case of single script, even if artificial, with a single set of | processing attributes). | | The reason for this question is that different scripts might have different | processing attributes for ordering which should not normally be mixed; if | scripts are not mixed in a given field to be compared, this does not pause big | technical difficulties and the POSIX model can be applied (except that for | characters formed by combining characters, this will require a mod of POSIX | specs, unless the full list of normal combinations is known, which is not the | case so far). | | If, on the other hand, scripts are mixed, and if one wants all processing | attributes to be taken into account for each script, then POSIX specs will | have to be changed or they won't be upward compatible with the multiscript | ordering model in preparation. | | There are solutions to both preferences (I already presented my views in the | 4th UNICODE implementation workshop, end of 1992, in Frankfurt), but there are | compatibility impacts in the second case more than in the first. The first | preference would allow far more efficient implementations too, but that should | not be an absolute criteria to preclude option 2 if this is a strong | requirement. | | I wish I am not too obscure to be understood by all the forums to which I am | sending this request. | | Alain LaBont | Gouvernement du Qubec | Secrtariat du Conseil du trsor | 1500B, boul. Charest Ouest, 1er tage | Ste-Foy (Qubec), Canada G1N 2E5 | Fax: +1 418 646 3571 | Tel: +1 418 644 1835 | Email: either ALB@IMMEDIA.CA or ALB@SHE.ORG.UK | | Editor of Default Tailorable Ordering Standard for the Universal Coded | Character Set (so called UCS, i.e. ISO/IEC 10646) | (Ordering Project: ISO/IEC Project 22.30.02.02) | |