Subject: RE: (SC22WG20.866) Multiscript Ordering -- Survey on a fundamental issue

From: Asmus Freytag <[email-masked]>
Date: Fri, 25 Feb 94 12:19:11 PST

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:  <[email-masked]>
| To:  <[email-masked]>;  <[email-masked]>;  <[email-masked]>;
| <[email-masked]>;  <[email-masked]>
| Cc:  <[email-masked]>;  <[email-masked]>;
| <[email-masked]>
| 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<e'>
| Gouvernement du Qu<e'>bec
| Secr<e'>tariat du Conseil du tr<e'>sor
| 1500B, boul. Charest Ouest, 1er <e'>tage
| Ste-Foy (Qu<e'>bec), Canada  G1N 2E5
| Fax: +1 418 646 3571
| Tel: +1 418 644 1835
| Email: either [email-masked] or [email-masked]
|
| 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)
|
|