SC22/WG20 N774
L2/00-307
Collection of reactions to the WG20 convenor's
"Personal thoughts about the future of WG20"
Part 1: August 30 through September 6, 2000
Akio Kido suggested that I collect all reactions to my proposal about the future of WG20 in one document for easy reference. Due to the interest in this subject, it became a rather lengthy document and I decided to put a linked index in front of it – that allows you to go straight to the contribution that interests you. I did not do any formatting – please apologize, if text in html does not look as good as it could be, but I wanted to maintain the original form of the e-mails the way I received them.
The document got too long – I had to split it into parts:
|
Parts |
SC22/WG20 |
NCITS/L2 - UTC |
|
Part 1, from August 30 – September 6, 2000 |
||
|
Part 2, from September 6 on … |
Index with the latest document on top:
|
National Body |
Name |
Date |
Content |
Supports |
|
USA |
Asmus Freytag |
2000-09-06 |
Y |
|
|
Canada |
Dave Blackwood |
2000-09-06 |
N |
|
|
Norway |
Keld Simonsen |
2000-09-06 |
N |
|
|
USA |
Ken Whistler |
2000-09-06 |
Y |
|
|
Germany |
Marc Küster |
2000-09-06 |
?N? |
|
|
Sweden |
K.I. Larsson |
2000-09-05 |
Y |
|
|
USA |
Ken Whistler |
2000-09-05 |
Y |
|
|
Canada |
Alain LaBonté |
2000-09-05 |
N |
|
|
Ireland |
Michael Everson |
2000-09-05 |
Y |
|
|
Ireland |
Michael Everson |
2000-09-05 |
Y |
|
|
Ireland |
Michael Everson |
2000-09-05 |
Y |
|
|
Japan |
Akio Kido |
2000-09-01 |
Y |
|
|
Germany |
Marc Küster |
2000-09-01 |
Y |
|
|
Sweden |
Ken Karlsson |
2000-09-01 |
Y |
|
|
UK |
John Clews |
2000-09-01 |
?N? |
|
|
Japan |
T.K. Sato |
2000-08-31 |
Y |
|
|
Norway |
Keld Simonsen |
2000-08-31 |
N |
|
|
Sweden |
Kent Karlsson |
2000-08-31 |
Y |
|
|
Japan |
Masayuki Takata |
2000-08-30 |
Y |
|
|
Japan |
Akio Kido |
2000-08-30 |
Y |
|
|
SC22 N 3164 |
Arnold F. Winkler |
2000-08-30 |
Y |
Individual contributions on e-mail:
Japan, Akio Kido, August 30, 2000
I agree with Arnold's thought.
It is good idea to work in the CLAUI. Some of our standard and TR are
tightly related with ISO/IEC 10646, and without having the involvement
of SC2, we can not maintain those IS and TR and make them alighn
with the latest ISO/IEC 10646. It is moving target to follow ISO/IEC
10646. So we do need to work togather with SC2.
Best regards,
Akio Kido (Globalization CoC, Yamato, IBM & Co-chair person of Li18nux)
Japan, Masayuki Takata, August 30, 2000
As an individual, I totally agree with your thoughts. Thanks for the
good ideas. This is not a small thing for us all, so it will take some
time to achieve conclusion in the Japanese working group. However, I have
no doubt that we will agree with you, at least in principle.
As the Head of Japanese equivalent of WG20, I'll try to find a group
consensus and, probably, delegate Kido-san to discuss in the SC22 Nara
Plenary.
Regards,
TAKATA Masayuki
Sweden, Kent Karlsson, August 31, 2000
I
agree in principle with your suggestions (with the
exception that I would prefer the withdrawal
also of 14652,
assuming that no-one is willing to rewrite it
from scratch
foregoing POSIX compatibility; similar problem
with the
registry standard).
From
a formal point of view, the responsibility of
SC22/WG20 matters within the Swedish NB was very
recently
transferred from our AG22 to our AG2, which
takes care of
TC304, SC2, SC35, and now also SC22/WG20
matters. So from
an NB point of view, a transferral of most WG20
projects
to SC2 would (now) not make any difference.
Kind
regards
/kent
k
Norway, Keld Simonsen, August 31, 2000
> Friends,
>
> After some hefty thinking and soul-searching, I decided to send the attached
> personal contribution to SC22 for consideration at the plenary in Nara. I
> will also send it to CLAUI for consideration at their meeting in October in
> France. I wanted you to see it before the official SC22 distribution.
>
> I do hope, you agree with me, at least in parts.
I think it is good that you have done some thinking about it.
I do think that WG20 has a role to play.
In my mind we are now about to begin the real work of WG20.
WG20 was set up to standardize i18n functionality, that is
APIs and also to find out what i18n is all about.
We have completed (more or less) location of i18n and
(with the usual time that it takes) now standardized
kind of what was standardized in other WGs of ISO wrt. i18n.
Then we have done a littel more, extended some specifications,
and we made 14651.
So now we are "lords in our own house", and we can begin
standardizing APIs and go beyond standard i18n functionality.
There are a lot of functionality to cover, before we can have
truly internationalized, portable applications.
I think the standardization of APIs and formats for data
specifications are best done in SC22, which standardizes
libraries, and also interacts with the many ISO programming languages.
Moving WG20 activities into SC2, as Arnold Winkler proposes, would be an error, IMHO.
APIs are not in the scope of SC2. Neither are sorting or
character attributes. And sorting and character attributes
have for a long time been a SC22 issue, viz. C, and other
programming languages islower(), isupper() etc. I do not
see the kind of expertise in character attributes at SC2 meetings,
but maybe they are available in Unicode, as the Unicode
Technical Commitee chair, Arnold Winkler, is hinting at, and maybe
we should just leave everything to Unicode, and stop making open
world-wide standards. In that way all our culture, not just
our MacDonald hamburgers, can be really standardized:-)
Kind regards
Keld
Japan, T.K. Sato, August 31, 2000
Arnold, you are going to make what I wanted.
I agree with you in principle. For each details, such as 2375 extension,
I think some more discussion might be necessary.
Sato
United Kingdom, John Clews, September 1, 2000
I'm sending my thoughts via <SC22WG20@dkuug.dk> which is probably
similar in content to the list of individuals.
I think Keld Simonsen sums up several of the things I'd considered
myself, and I find myself agreeing with several of his points, as
noted below: I also throw in some other issues which may be related
to the wider picture.
In message <20000831202309.A3987@rap.rap.dk> Keld wrote:
> I do think that WG20 [still] has a role to play...
> WG20 was set up to standardize i18n functionality...
No other ISO/IEC JTC1 committee is doing this at present, although we
should certainly continue our liaison within and outside of ISO/IEC
JTC1 committees - in fact JTC1/SC22/WG20 seems to be quite good at
that.
It's also an ideal size working group in terms of size, cost
effectiveness, and in what it can get done.
> We have completed (more or less) location of i18n and
> (with the usual time that it takes) now standardized
> kind of what was standardized in other WGs of ISO wrt. i18n.
> Then we have done a littel more, extended some specifications,
> and we made 14651...
Which is certainly our big success story, also involving extremely
valuable liaison and participation with the Unicode Technical
Committee. This still needs more work in its second edition.
> There are a lot of functionality to cover, before we can have
> truly internationalized, portable applications.
>
> I think the standardization of APIs and formats for data
> specifications are best done in SC22, which standardizes
> libraries, and also interacts with the many ISO programming languages.
>
> Moving WG20 activities into SC2, as Arnold Winkler proposes,
> would be an error, IMHO.
> APIs are not in the scope of SC2. Neither are sorting or
> character attributes. And sorting and character attributes
> have for a long time been a SC22 issue, viz. C, and other
> programming languages...
> I do not
> see the kind of expertise in character attributes at SC2 meetings,
> but maybe they are available in Unicode, as the Unicode
> Technical Commitee chair, Arnold Winkler, is hinting at...
Unicode Consortium and the UTC have an extremely important role.
So does ISO, in enabling more international input at expert level
than the UTC does on its own.
It may be useful to have view on this (not necesarily official) from
the UTC, or somebody within it.
The UTC and ISO/IEC JTC1/SC2/WG2 make a valuable complementary pair:
the UTC and ISO/IEC JTC1/SC22/WG20 also make a valuable complementary
pair.
In passing I also notice that comments from Europe that I have seen
tend towards keeping ISO/IEC JTC1/SC22/WG20, and that comments from
the USA and Japan that I have seen tend towards moving away from
ISO/IEC JTC1/SC22/WG20, although I wouldn't read anything too much
into that.
However, it does reminds me that the European Commission has
commissioned Price Waterhouse Coopers, if I have the details correct,
to evaluate future work in CEN/TC304: Information and Communications
Technologies: European Localization Requirements.
Considering the degree of overlap of some aspects of work between
ISO/IEC JTC1/SC22/WG20 and CEN/TC304, and between the Unicode
Technical Committee and CEN/TC304 to a lesser degree (probably
complementing each other rather than overlapping) it may be useful for
ISO/IEC JTC1/SC22/WG20 and/or the UTC to provide some input into that
process in due course as well, to see if this work can also provide a
wider picture of a useful future in ICT standardisation.
Best regards
John Clews
Sweden, Kent Karlsson, September 1, 2000
> -----Original Message-----
> From: Keld Jørn Simonsen [mailto:keld@dkuug.dk]
...
> I do think that WG20 has a role to play.
> In my mind we are now about to begin the
real work of WG20.
> WG20 was set up to standardize i18n
functionality, that is
> APIs and also to find out what i18n is all
about.
> We have completed (more or less) location
of i18n and
> (with the usual time that it takes) now
standardized
> kind of what was standardized in other WGs
of ISO wrt. i18n.
> Then we have done a littel more, extended
some specifications,
> and we made 14651.
>
> So now we are "lords in our own
house", and we can begin
> standardizing APIs and go beyond standard
i18n functionality.
> There are a lot of functionality to cover,
before we can have
> truly internationalized, portable
applications.
>
> I think the standardization of APIs and
formats for data
> specifications are best done in SC22, which
standardizes
> libraries, and also interacts with the many
ISO programming
> languages.
>
> Moving WG20 activities into SC2, as Arnold
Winkler proposes,
> would be an error, IMHO.
> APIs are not in the scope of SC2.
True, API development/standardisation should
not be done in SC2.
But nobody is suggesting that is should.
The suggestion is to
cancel the API standard development of WG20, due
to lack of
interest and lack of quality. What is
troubling is that if
14652 and the corresponing API standard
continue, Linuxers
and C (C++, POSIX) standardisers will be
misguided by them.
The only hope for the i18n file format and API
standards to
be of any use would be to start over from
scratch, essentially
ignore POSIX, but pick up the very best from the
others, and
do something completely new. But I don't
see that happening in
WG20 at this time.
> Neither are sorting or
> character attributes. And sorting and
character attributes
> have for a long time been a SC22 issue,
viz. C, and other
> programming languages islower(), isupper()
etc. I do not
> see the kind of expertise in character
attributes at SC2 meetings,
> but maybe they are available in Unicode, as
the Unicode
> Technical Commitee chair, Arnold Winkler,
is hinting at,
Character attributes and ordering certainly
belongs in SC2.
That's where the expertese about such matters is
to be found
within ISO, not in SC22. C (and C++ and
POSIX) has botched
both character and character string
representation, as well
as character properties. C does NOT specify what
wchar_t is,
leaving open to each implementation to do
whatever, nor does
it specify any other suitable datatype, and what
char is is
locale-dependent. Ada fares a bit better on that
point where
Wide_Character and Wide_String are UCS-2 (except
in non-conforming
implementations). In C (and C++ and POSIX)
islower etc. are
locale-dependent, not character-dependent. C and
POSIX are
definitely the wrong places to look for guidance
regarding this.
> and maybe
> we should just leave everything to Unicode,
and stop making open
> world-wide standards. In that way all our
culture, not just
> our MacDonald hamburgers, can be really
standardized:-)
I find that statement to be uncalled
for. In my experience
Unicode consortium is quite open to input, more
so than
ISO, and definitely more so than W3C, and
extremely much
more so than TC304... And the results from
Unicode consortium
are also more open than those from ISO.
> -----Original Message-----
> From: Ordering@sesame.demon.co.uk [mailto:Ordering@sesame.demon.co.uk]
...
> However, it does reminds me that the
European Commission has
> commissioned Price Waterhouse Coopers, if I
have the details correct,
> to evaluate future work in CEN/TC304:
Information and Communications
> Technologies: European Localization
Requirements.
"European Localisation
Requirements" sounds good. Unfortunately
TC304 has come up with some rather useless
'delivarables':
reports that misrepresent Unicode/10646, and
seem to argue for
increased use of ISO 2022 (currently at about 0%
usage in Europe);
botched MES-1 and MES-2 subsets, lacking MES-3
subsets; a report
on fall-back that is hopelessly outdated;
"euro-locales" based
on POSIX 'locales' and that in addition are
ambivalent to
localisation (common ordering, but language
varying week/month
names); not to mention an internal quarrel about
*exactly* what
constitutes Europe (as if that really mattered
for TC304).
And the involvement of IT (and communication)
industry in
TC304 has, as far as I can tell, been extremely
small.
Kind
regards
/kent
k
Germany, Marc Küster, September 1, 2000
Dear Colleagues,
> > After some hefty thinking and soul-searching, I decided to send the attached
> > personal contribution to SC22 for consideration at the plenary in Nara. I
> > will also send it to CLAUI for consideration at their meeting in October in
> > France. I wanted you to see it before the official SC22 distribution.
> >
> > I do hope, you agree with me, at least in parts.
>
Arnold's thoughts are indeed stimulating and not unfounded. 14651
certainly is WG20's most relevant project at this point in time, and it is
going to become an international standard very soon now. While there is
the need for immediate revision to cover at least the
repertoire of 10646-1:2000, end is in sight.
There is no point in keeping WG20 as a cosy debating club.
[Keld]
> I do think that WG20 has a role to play.
Still, I do agree with Keld that WG20 may have a role to play. Whether it
is currently doing so in the best possible manner is open to debate -- you
know the German views on both 14652 and the API standard --, but that does
neither mean that such work is superfluous nor that there is a lot of
value in WG20s deliverables.
When we agreed in Québec to look for "customers" of WG20's deliverables,
especially for the API standard, it was in this spirit. If no-one is
interested in them, by all means cancel them. Yet, I think it is
worthwhile to try. If that may take, as Kent suggests and I agree, drastic
overhaul of the papers, why not?
Moreover, John is right in pointing to the market study that the European
Commission has ordered on CEN/TC304 and that is to be delivered within a
few months. This study by Price Waterhouse Coopers may or may not filter
out important new areas of work for TC304, it may recommend anything in
between closure and drastic extension of responsibilities. In any case
many of the conclusions they draw on a European level will be of value to
WG20, and it is worthwhile to scrutinize them before taking action either
way.
What I am driving at is not keeping WG20 alive at all cost, quite on the
contrary. I'd, however, counsel patience and level-headed evaluation of
the development of the next six months.
Best regards,
Marc
***************************************************
Marc Wilhelm Kuester
Computing Centre of the University of Tuebingen
Dept. Literary and Documentary Data Processing
Japan, Akio Kido, September 1, 2000
I think what Arnold proposes NOT simple termination of WG20 work,
rather he proposes to work at more appropriate place.
I like to understand the point why some people stick the current WG20.
I'm talking about just organization view point. I personally observe that
other WGs in SC22 might have less interests on the further work of WG20,
since we have quite less participateion of representatives from other
working groups in our meeting. Rather, I observe, they might pay
more attention to ISO/IEC SC2 and Unicode works.
Of course, if we start to work in a new group, we should discuss
our futher works from the scratch. In order to do that, we need to
cancel our projects that have not yet reached to final stage, once.
If an existing projects still has importance to market, we can issue NWI again
with new workable business plan.
I beleive that what we need to discuss is NOT the importance of
some existing work, but is where and how we can contribute internationalization
in a timely manner. We should recognize that some of our projects are delaying.
As convenors report said, we can not put priority to API standard, although
the ISO 3 years timer was already expired.
The reson why I agreed with Arnod is that I think he proposes some
work-able actions.
1) Complete ordering standard ASAP
2) Terminate WG20 activity onece.
3) Bring some work that require maintanance to appropriate groups.
( those who are interesting in the maintanance work can join the group ).
That proposal would also impley,
a) if no one interesting in some WG20 works which require maintanance,
those standard or TR should be frozen.
b) the project that we can not put priority in the current WG20, has a
chance to re-evaluate its importance and re-start in a new group.
( Of course, if the projects can not have enough support and
participation, that projects should be dead project, we should
not re-start those canceled projects. )
Best regards,
Akio Kido (Globalization CoC, Yamato, IBM & Co-chair person of Li18nux)
Ireland, Michael Everson, September 5, 2000
I am in complete agreement with Arnold's contribution. The only thing I
would say is that I would like the plan for how SC2 is to take over
responsibility for the 14651 table to be elaborated. On the other hand
maybe that is an SC2 matter.
Michael Everson ** Everson Gunn Teoranta ** http://www.egt.ie
Ireland, Michael Everson, September 5, 2000
>Character attributes and ordering certainly belongs in SC2.
Maintaining ISO standards on the character attributes would unfairly burden
SC2 and it would be impossible to make timely changes, such have been made
numerous times as the bugs in the bidi algorithm have been ironed out.
Industry (UTC) is the right place for that work, as it is eminently
practical. The Generic Ordering Template is easier to maintain and has
already been standardized.
Michael Everson ** Everson Gunn Teoranta ** http://www.egt.ie
Ireland, Michael Everson, September 5, 2000
>Moving WG20 activities into SC2, as Arnold Winkler proposes, would be
>an error, IMHO. APIs are not in the scope of SC2. Neither are
>sorting or character attributes.
Character attributes should not be maintained by SC2 because of the nature
of the ballotting process. But you are wrong that sorting is not in the
scope of SC2. ALL of these scripts when presented for encoding have had
ordering scrutinized by WG2 experts in order to put the code tables
together. All the expertise for this is in the UTC and in WG2. To maintain
the default table, it is logical and natural for SC2 to handle this,
whether in WG2 or a new WG4.
The script and linguistic expertise is NOT available in the Programming
Languages subcommittee.
Michael Everson ** Everson Gunn Teoranta ** http://www.egt.ie
Canada, Alain LaBonté, September 5, 2000
Outcome of our Québec 2000-09-05 CAC/SC22 meeting on this issue
Generally speaking: I18N is a fundamental requirement on programming
languages (PL) and PLs don't take care enough about it (currently APL,
COBOL, C, POSIX, ADA and FORTRAN communities have dealt with such issues to
acertain point, and most others have notr at all; those who did something
did not completely do what needs to be done), that maybe the main problem.
We lose something if we weaken SC22/WG20 too much, if we do not cancel it.
I18N issues need to be reminded all the time to the PL community at least
in Plenaries. The CPL community think this would be a big loss and probably
a mistake at least for this reason. If SC2 takes the lead of most
of SC22/WG20's program of work, programming language i18n will be
neglected even more than today.
On the other hand we know that most, if not all, SC22/WG20 experts are
already working too in SC2, and SC22/WG20 and SC2 work is already
integrated in some countries, including Canada, due to the small community
of experts. That would continue anyway.
There is a need for the i18n community to keep a handle on PL activities.
SC22/WG20 needs to reflect on the reshuffling of current and maintenance
work to perhaps have a greater impact on ISO/IEC PL activities. Canada
would be in favour of reexamining all work having this as a goal.
Secific work:
IS 14651 Sort Standard: can be anywhere... it has to be in SC22 or in
SC2... SC22's advantage would be to maintain the thing open to PL standards
development more. It is sure that SC2's strong collaboration is required,
and if it were in SC2, strong collaboration would also be required from the
PL community.
TR 14652 Specification Method for Cultural Conventions: It is indeed POSIX
oriented but the POSIX WG always said it belonged to WG20... The POSIX WG
now has a lot of challenges and it would not be timely to transfer that
project there (to WG15). Perhaps we need to de-emphasize the perception
that this has more to do with POSIX than with PLs, a perception which
should be wrong, otehrwise the TR has at least partly failed. Controversial
issues should be removed and the TR should be enhanced in WG20, with strong
collaboration with SC2.
ISO/IEC 15435 API standard project: we believe in Canada that an I18N API
standard is required, and that otherwise kitchen-made solutions will rather
tie customers to some developers, which is the opposite goal of
international standards. If the current proposal is not OK, then we should
at least try, in a short-time study with a precise deadline, if at all
possible without annoying intellectual property, to find the commonalities
of what is being done by producers and see if we can make a standard with
it or at least a TR. That would belong in SC22 in Canada's opinion.
ISO/IEC 15897 Cultural Registry: Canada believes that this should be
managed in the same way as the Character set Registry with an advisory
group. This advisory group could very well be formed with a mix
representation from SC22/WG20, SC2 and perhaps SC35 (User interfaces). As
everybody said in the past, what we need is an independent "IBM green book"
(National Language Design Guide volume 2). We believe that this registry is
about this and should be marketed better. This data is required by a lot of
communities in JTC1 and even electronic commerce standards community
demonstrated an interest in this in the BT-EC report.
TR 10176 Programming languages standards guidelines: its annex on
identifier-related characters is in our opinion linked to SC2's interests,
while all the rest belongs to SC22. Again a strong collaboration between
SC22 and SC2 is required. The place for maintaining this appears to be in
SC22/WG20.
Other issues: a lot of I18N issues belong to the user interface domain.
This is dealt with in SC35. We should remember that the whole domain of
I18N is a horizontal issue in JTC1 and that cultural and linguistic
adaptability remains a strategic thrust of that super-committee. The TD on
CLAUI will hold a meeting in Southern France in October. That should be an
opportunity for SC2 and SC22's convenors and editors to reflect on all
these problems and come up with a plan for the reshuffling of those
activities in the whole of JTC1, but more particularly in SC22/WG20 and SC2.
USA, Ken Whistler, September 5, 2000
Many thanks to Alain for providing a timely report of the deliberations
on this topic at the CAC/SC22 meeting.
I have a few observations on some of the conclusions that Alain
and his colleagues reached.
> Outcome of our Québec 2000-09-05 CAC/SC22 meeting on this issue
>
> Generally speaking: I18N is a fundamental requirement on programming
> languages (PL) and PLs don't take care enough about it (currently APL,
> COBOL, C, POSIX, ADA and FORTRAN communities have dealt with such issues to
> ascertain point, and most others have not at all; those who did something
> did not completely do what needs to be done), that maybe the main problem.
> We lose something if we weaken SC22/WG20 too much, if we do not cancel it.
> I18N issues need to be reminded all the time to the PL community at least
> in Plenaries. The CPL community think this would be a big loss and probably
> a mistake at least for this reason. If SC2 takes the lead of most
> of SC22/WG20's program of work, programming language i18n will be
> neglected even more than today.
My main concern here is that the problem of internationalization
is somewhat misconstrued here as a "requirement on programming
languages." Some of the deep trouble that WG20 is in is the result
of attempting to conceive internationalization as being in the
domain of formal programming languages, and thereby setting up an
agenda to create standards that can be grafted back onto a whole
host of PL's. This is, I am afraid, bound to fail, since it is taking
an inherently complex field, full of user-specific cultural behavior,
and trying to find a way to bolt on extensions to existing programming
language standards (some of them *very* old, like COBOL and FORTRAN)
to deal with it.
I, instead, see the *appropriate* adaptation of the programming
languages to consist essentially of making sure they interoperate
with 10646 data and program text, since that seems to be the way
the world is heading. This should consist of specifying that the
languages will work with UTF-8 (as well as Shift-JIS, or whatever)
as program text, and to allow arbitrary textual content into comment
fields, for example. And the C standard has adjusted the definition
of wchar_t to take UCS into account already.
*Maybe* some adaptations to extend identifier syntax should be