From greger@iuk Mon Nov 26 22:33:47 1990 Received: from ism.isc.com by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA03259; Mon, 26 Nov 90 22:33:47 +0100 Received: by ism.isc.com (Sendmail5.61/1.35) id AA03017; Mon, 26 Nov 90 13:37:23 -0800 Received: from friherr by iuk.isc.com (5.61/smail2.2/11-14-88) id AA24596; Mon, 26 Nov 90 21:14:20 GMT Received: by (5.61/1.35/jcb-s) id AA00399; Mon, 26 Nov 90 21:25:45 GMT Date: Mon, 26 Nov 90 21:25:45 GMT Message-Id: <9011262125.AA00399@> To: i18n%dkuug.dk@ism, XoTGinter@xopen From: greger@ism.isc.com ("greger@ism.isc.com (Greger Leijonhufvud, ISC, High Wycombe, U.K.)") Subject: Strawman resolution to ballot objections X-Charset: ASCII X-Char-Esc: 29 Several balloteers in the last ballot on 1003.2 has objected to the internationalization efforts, largely based on a view that rules for the creation and definition of character sets, character classes, or collation sequences is not required for applications portability, and that the facilities (Chapter 2.5) are largely untried and therefore should not be made part of the standard. On the other hand, the international community feels that the ability to specify a particular behavior in a manner which is portable is an important part of a standard which intends to provide good facilities for the international community. The following proposal is an attempt to resolve this conflict. It is based on the idea that there are three levels of support required. If accepted, the resolution of several ballots will be based on this scheme. 1. C locale support. This environment does support only one character set and encoding, and the only locales supported is the "C" or "POSIX" locale. As noted in the current draft, implementors can make certain extensions to the C locale, mainly in the support of the full 256 characters in the character set (additional characters in the character classes, additional characters in the collation sequence). Rationale: As the standard only defines one specific locale, the "C" or "POSIX" locale as mandatory, an implementation can provide this level of support (which essentially defaults to an "old-style-UNIX) and still be POSIX compliant. While the localedef utility is still required, is could always return an error. Likewise, the locale utility is required, but the output can be progranmmed in. Note that implementations can make certain extensions to the C locale definition, mainly in the support of 256 characters in char classes and/or collation. 2. Basic Internationalization Support. Implementations shall support one or more character sets and encodings. Each character set shall be documented via a charmap; users may not define new character sets, but may add symbolic names for characters in implementation-supplied charmaps. Implementations shall provide a C locale and may provide additional locales. Users may also add locales. Rationale: This is the minimum level required for an "internationa- lized" system. For the parts that are covered by POSIX, it also corresponds fairly well with the requirements specified in X/Opens Portability Guide, Issue 3 (XPG3), as well as with the capabilities widely available in commercial implementations. 3. Extended Internationalization Support. Implementations shall support one or more character sets and encodings. Each character set shall be documented via a charmap. Users may add symbolic names for characters in the implementation- supplied charmaps. It is implementation defined whether users can define new character sets (charmaps). Rationale: This level of support is required for e.g. Asian locales (added LC_TIME keywords), currently proposed collation standards, etc. Implementations aiming for worldwide commercial acceptance probably will need this level. Category Level Interpretation ---------------------------------------------------------------- LC_CTYPE C-locale Implementation-supplied character classification support only. Basic User specification of character classification according to rules defined in 2.4.1, but no additional classes may be specified. Extended As above, but additional classes may be specified. LC_COLLATE C-locale Implementation-supplied collation as per the implementor's C locale. Basic Implementations shall support multi-character collation elements and collation symbols, 1-to-2 mapping and user-specified 2-level ordering, with both forward and backward compares. The "substitute" keyword and the "no-substitute" and "position" collation directives are optional. Extended Same as basic, but with 1-to-many mapping and support for the "substitute" keyword and the "no-substitute" and "position" collation directives, and with at least 3 weight levels (possibly four). LC_MONETARY C-locale Implementation-supplied localeconv() (or equivalent) support for C locale. Basic Implementations shall support user- definable values for all keywords. Extended Currrently same. LC_NUMERIC C-locale Implementation-supplied localeconv() (or equivalent) support for C locale. Basic Implementations shall support user- definable values for all keywords. Extended Currrently same. LC_TIME C-locale Implementation-supplied C locale support for the C locale field descriptors %a, %A, %b, %B, %c, %x, %X and %p. Basic Implementations shall support user- definable values for keywords abday, day, abmon, mon, d_t_fmt, t_fmt, d_fmt and am_pm. Extended Same as above, plus support for optional keywords LC_MESSAGES C-locale Implementation-supplied support for C locale responses and C locale messages Basic Implementations shall support user- definable values for yesexpr and noexpr. Extended Same. LC_TIME: Implementations shall support the keywords abday, day, abmon, mon, d_t_fmt, d_fmt, t_fmt and am_pm. At runtime, applications can verify the level of support via the following implementation limits: LOCALE_SUPPORT 0 C locale only LOCALE_SUPPORT 1 Basic support LOCALE_SUPPORT 2 Extended support WEIGHTS_MAX (1) Number of weight levels supported in collation (minimum level is 1). This replaces EQUIV_CLASS_MAX. I would appreciate your comments on this scheme A.S.A.P.... Greger Leijonhufvud INTERACTIVE Systems greger@{iuk,ism}.isc.com