Canadian contribution based on the ISO/JTC1/SC22/I18NRG March 2005 agenda

 

Date: 2005-03-03

 

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

 

 

6.1 Existing WG 20 projects.

 

[Canada]

I18n APIs mandated by SC22 2001 Plenary? Does SC22 need common specifications?

 

 

6.2 Maintenance of WG20 generated Standards.

[Canada]

 

 

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.


[Canada]

 

 

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.