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]

• TR 10176:2003 (Programming Language Guidelines) : Annex A for identifiers, in the future, reference to 10646 (see SC2/WG2 N 2895) ; if they want to point to it, fine, otherwise that would be a separate SC22 activity. Sold for 144 CHF.

 

• TR 14652:2004 Specification method for cultural conventions : sold for 200 CHF.

 

• Locale registry standard ISO/IEC 15897:1999 : Due for revision in 2005. Sold for 130 CHF.

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.

 

• ISO/IEC 11017 : published in 1998, status? Should have been reconfirmed (or revised) in 2003 Still sold by ISO 144 CHF. Canadian position: reconfirm immediately, then review and revise in line with what has been going on since 1998.

 

Developed initially by SC22, recently transferred to SC2 (but still usable by SC22 PLs, and perhaps already referenced, like in COBOL):

 

• ISO/IEC 14651:2001 Method for comparing Character strings and description of common template tailorable ordering  transfered to SC2. Sold for 144 CHF (available in English and French [Méthode de comparaison de chaînes de caractères et description du modèle commun et adaptable d'ordre de classement])
• Amd 1:2003 (sold for 16 CHF)
• Amd 2 (developed partly in SC22, partly in SC2): FDAM ballot ongoing (ITTF)
• Amd 3:development to begin in April in SC2 (NP+CD PDAM ballot)

6.3 Identify any new I18N projects.

[Canada]

• Biggest message (Steve Michell): we (SC22) still don’t understand what i18n means.
• SC35 (User interfaces) recently produced TR 19764 (in English and in French) on Guidelines, methodology, and reference criteria for cultural and linguistic adaptability in information technology products : this describes user expectations, perhaps SC22 could have a look on what is expected (this methodology is actually used in practice in Canada).
• SC35 also have new user-interface-related work relative to I18N which SC22 should follow.
• TR 11017 identifies a lot of I18N-related standards, this should be refreshed.
• Paris meeting of JTC1 CLAUI TD (JTC1N5629) also identified work to be done.
• SC2 Character sets and sorting: PLs still have work to do
• Other ISO TCs: example: Date and Time : many standards (ISO 8601 language neutral); no ISO std for time zones; what to do with this? Many countries have no time zone abbreviation. Many countries have no equivalent of English notions like AM and PM, used in some PLs.

 

 

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.