From keld@dkuug.dk Mon Nov 26 23:36:40 1990
Received: by dkuug.dk (5.64+/8+bit/IDA-1.2.8)
	id AA04063; Mon, 26 Nov 90 23:36:40 +0100
Date: Mon, 26 Nov 90 23:36:40 +0100
From: Keld J|rn Simonsen <keld@dkuug.dk>
Message-Id: <9011262236.AA04063@dkuug.dk>
To: XoTGinter@xopen.co.uk, i18n@dkuug.dk
Subject: Re:  (wg15rin 57) (i18n 28) Strawman resolution to ballot objections
X-Charset: ASCII
X-Char-Esc: 29

A quick reply to Gregers 3 level support for i18n in POSIX.
This is not neccesarily the position of Danish Standards.

DS has made an (example) national profile for POSIX.
This profile/locale is in accordance with the Danish standard
for collating DS 377. I do not believe that DS can endorse
a standard like POSIX which does not require facilities which is
neccesary to fulfill Danish Standards needs, including correct
collating in Danish. 

I would anticipate that quite some other national bodies will have 
the same requirements for sorting their language correctly.

I will state below what is neccesary to accomodate DS 377.

>    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.

The Basic level is necessary to be able to provide the DS da_DK locale.

> 		Extended        As above, but additional classes may
> 				be specified.

Not needed.

>   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).

Extended level is needed here, 4 levels needed, 1-to-many mapping
needed for 8859-1 support!

> 
>   LC_MONETARY   C-locale        Implementation-supplied localeconv()
> 				(or equivalent) support for C locale.
> 
> 		Basic           Implementations shall support user-
> 				definable values for all keywords.

Basic is needed.

> 		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.

Basic is needed.

> 		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.
Basic is needed.

> 		Extended        Same.

My quick conclusion: Implementations with C-locale like facilities
should not be sold in Denmark as conforming to ISO POSIX.

This is also in line with WG15's resolution that the support for i18n
as specified in POSIX.2 draft 10 is the minimum level of support
that is needed to accomodate international needs.

Keld Simonsen