Subject: Strawman resolution to ballot objections

From: [email-masked] ("[email-masked] (Greger Leijonhufvud, ISC, High Wycombe, U.K.)")
Date: Mon, 26 Nov 90 21:25:45 GMT

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