ISO/IEC JTC 1/SC22
Programming languages, their environments and system software interfaces
Secretariat: U.S.A. (ANSI)
ISO/IEC JTC 1/SC22 N 3875
TITLE: Canadian Contribution on the ISO/IEC JTC 1/SC 22 I18NRG March 2005 Agenda
DATE ASSIGNED: 2005-03-11
SOURCE: Canadian National Body
DOCUMENT TYPE: National Body Contribution
STATUS: This document will be reviewed at the upcoming I18NRG meeting. This document is located at: http://www.open-std.org/jtc1/sc22/open/n3875.htm
ACTION IDENTIFIER: FYI
25 West 43rd Street
New York, NY 10036
Telephone: (212) 642-4918
Fax: (212) 840-2298
Canadian contribution based on the ISO/JTC1/SC22/I18NRG March 2005 agenda
Status: Result of a Canadian brainstorming held on 2005-03-01
Editorial conventions in this document: agenda item identified in bold type, Canadian answer in normal type
Result of Canadian brainstorming on the agenda proposed by I18NRG, Mr. John Benito
I18n APIs mandated by SC22 2001 Plenary? Does SC22 need common specifications?
Maintenance of WG20 generated Standards.
Competing with CLDR (Common Locale Data Repository)
Hottest topic: try to converge on a standard which would be a merge of both. Deals with things of the past.
Developed initially by SC22, recently transferred to SC2 (but still usable by SC22 PLs, and perhaps already referenced, like in COBOL):
6.3 Identify any new I18N projects.
6.4 Management of non-project activities related to I18N.
[Canada] What does exist in all SC22 standardized PLs? A brief TR summary of what exists in all PLs standardized by SC22 would be required.
(Added agenda item 6.5) How to cooperate with others inside and outside SC22? (key: no work duplication).
Strong Canadian position: i18n is an important part of SC22.
What is required in SC22? How do we reorganize?
Have to send all this at a higher level: JTC1 has not articulated a roadmap for i18n. The rapporteur group could step in in doing that. What belongs to SC22, what does not belong.
What are the problems faced by programming languages?
Identifiers, things related to portable naming of objects, case folding and conversion, operating systems handling of i18n, portable locales, personalization, mapping of character sets, sorting, interoperability between systems (highly dependent on i18n), cataloguing, file systems, comments in any script, literals in any script.
On one hand, WG20 was perceived as POSIX-centered (by opposition to OO and Java), the opponents were perceived as too Unicode-consortium-controlled.
3 ways to reorganize:
Make it a mandate of Plenaries all the time (visibility but responsibility will be lost)
Create a new WG (visibility)
Create some kind of special working group managed more closely by SC22 than WG20 (has to be reconfirmed at each meeting)
Canadian recommendation: Re-creation of a WG, but co-location with SC22 Plenaries to manage it more closely. There are obvious horizontal relationships (with Linux [for example] and with traditional WGs).
However, this WG should be created when SC22 has understood clearly what i18n means for the Programming Language Standards developers and once it has identified specific topics of interest. Finally it goes without saying that a sufficient number of national bodies have to be identified prior to any NP ballot that would be preliminary to the creation of a WG.