SC22/WG20 N922

From: Ulrich Drepper [drepper@redhat.com]
Sent: Thursday, March 28, 2002 8:44 PM
To: Winkler, Arnold F

Subject: comment regarding 14652



It has been brought to my attention that one side of the discussion about
the continuation of ISO/IEC DTR 14652 is using the GNU C library as an
argument.  For those who don't know me, I'm the maintainer and main
developer of the GNU C library (glibc) and I'm also responsible for
developments like GNU gettext.  Nobody but me worked on the architecture
of the i18n support in glibc so what I'm writing here cannot be
disputed.

When I started in 1996 adding i18n support I soon realized the, how to
put it nicely, limitations of the original POSIX model.  Not all
required functionality could be implemented with support from the
locale.  Examples are the wcwidth()/wcswidth() interfaces,
transliteration support in iconv(), better default (esp for printers ->
paper format).

When at that time Keld Simonsen sent me one of the very early drafts for
14652.  It contained support for some of the functionality I was missing
and inexperienced (both the i18n issues and the user's acceptance of
them) I included support for large parts of the draft in glibc.  The
result was in glibc version 2.1.

Today the code is still present (and it will continue to be so) and some
of the extensions are actually in use:

- the transliteration information is used in iconv() as one possible
transliteration mechanism

- the paper width/height information is used to make intelligent guesses
regarding the default paper format

- the character width information is used to implement
wcwidth()/wcswidth()

- some of the LC_COLLATE input format extensions are needed to more
intelligently implement ISO 14651

There might be some other uses which currently slip my mind and some
which users of glibc found useful.


There are a number of points to note:

1. The fact, that I implemented the extensions back in 1998/1999 does
not mean that I endorse the draft standard.  It only means that I needed
something and used what was available.

2. I have not changed the implementation to follow any of the changes
made after the draft I based my work on.  This does not mean that I
followed that draft blindly in the first place.  It contained
requirements which didn't make any sense or were contrary to my
experiences.  As mentioned, I didn't consider the usability aspect back
then.

3. Since the time the changes to glibc were made I've learned about the
true extend the locale functionality is really used.  Most of the
proposed new functionality is even less useful than what is already in
the POSIX locale.  Adding these features would just add costs without
the slightest benefit.


I am eager to make some more locale information available to users but
it first has to be determined who needs what and how it would be used. 
This all has to wait until the global POSIX locale model is changed. 
But I digress...


The point I'm trying to make here is that nobody should take the
argument "glibc uses it" serious.  If I as the author who should be the
strongest defender say this you might want to believe it.  Nobody should
support the proposal for the "this is better than nothing" reason since
most of the additional information proved to be not usable, at least in
the current form.  In my opinion it is time to start from scratch and to
do this the 14652 draft must be rejected and withdrawn.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------