SC2/WG2 N2722 cover

SubjectSource
Distribution
ActionDate(SC22docs.2068) N3725-Summary of Voting on N3673, Letter Ballot o n the Japanese
National Body Contribution to JTC 1/SC 22 to Request that JTC 1/SC 2 Consider
Putting Specification of the Character Repertoire for Identifier on the SC 2
Programme of WorkSC22 Secretariat – Sally Seitz – forwarded by Mike Ksar SC2/WG2 Convener
SC2/WG2 Experts and Liaison organizations
FYI
2004-03-11

ISO/IEC JTC 1/SC22 N3725

TITLE: Summary of Voting on N 3673, Letter Ballot on the Japanese National Body Contribution to JTC
1/SC 22 to Request that JTC 1/SC 2 Consider Putting Specification of the Character Repertoire for Identifieron the SC 2 Programme of WorkDATE ASSIGNED: 2004-03-11
SOURCE: SC22 Secretariat
BACKWARD POINTER:
DOCUMENT TYPE: Summary of Voting
PROJECT NUMBER:
STATUS: SC 22 National Bodies have approved this ballot. The Japanese National Body is requested toincorporate the comments received on this document and provide the Secretary with the new document forsubmission to SC 2. This document is located at: http://www.dkuug.dk/jtc1/sc22/def/n3725.pdf

ACTION IDENTIFIER: FYIDUE DATE:
DISTRIBUTION: PDF
CROSS REFERENCE: N3673
DISTRIBUTION FORM: Def

Address reply to:
ISO/IEC JTC 1/SC22 Secretariat
Sally Seitz
ANSI
25 West 43rd Street

New York, NY 10036
Telephone: (212) 642-4918
Fax:(212) 840-2298
Email: sseitz@ansi.org

Voting Summary on JTC 1/SC 22 N 3673
P-Member
Austria
BelgiumBrazilCanadaChina
Czech Republic
Denmark
Egypt
FinlandFranceGermany
IrelandItaly
Japan
DPR of Korea
Republic ofKorea
Netherlands
NorwayRomania
RussianFederationSlovenia
Switzerland
UkraineUnited Kingdom
United States

Approve Approve
w/CommentsDisapprove Abstain

XXXXX

AbstainXX (see below)

Comments:
United States:
The U.S. supports with comment, proposal N3673 that SC22 make a request toSC2/WG2, such that when SC2/WG2 add new characters to ISO 10646, that SC2/WG2also specifies those new characters that would also be acceptable as identifiers.

The comments are:1) Having the JTC1/SC2 program of work include this project (as outlined in SC22N3673) would allow for timely and continuous synchronization with the repertoire ofISO 10646/Unicode, as future amendments of 10646 are adopted.
2) The work of identifying extended characters is likely to have broad interest to JTC1
subcommittees, such as SC7, SC11, SC22, SC23, SC25, SC28, SC31, SC32, SC34, SC35,and SC36. It is recommended that this work be circulated at the JTC1 level so that JTC1
subcommittees may be better informed of these SC2 activities, and so that JTC1
subcommittees may harmonize their work with the SC2 activities.
In addition to identifying extended identifier characters, it may be important for many
ICT applications to know what characters are also considered extended digit characters,extended letter characters, and other classes of extended special characters.
In prior work on extended identifiers, knowledgeable experts provided advice andguidance that helped properly classify characters. It would be extremely helpful tocapture this knowledge in a "rationale/criteria annex" or a companion technical report sothat users of these classifications could be better informed about the intended uses, thespecial circumstances, the limitations, and so on.
While it is not necessarily a classification function, certain relationships are important forcommon operations on identifiers, such as the familiar upper-lower case usage in Latin
letters (e.g., leading capitals, "camel case", etc.). It has been discovered that additional
character transformations for identifiers are in use in non-Latin scripts in ICT
applications (e.g., full vs. half width for Japanese identifiers). It would be helpful if thecharacter set experts in SC2 could identify some of these popular conventions so that they
could be better understood and processed more consistently in ICT environments.
3) As long as this change involves* asking SC2 to specify those characters which they believe are suitable for identifiers,but* leaves each programming language standard (and SC22 and other SCs and work
programs generally) free to specify its own
identifier-character list after considering the tradeoffs between its requirements and theadvantages of a consistent, single, identifier
specification, then this proposal and position seems entirely appropriate. However, this is
not clear from either the draft letter nor
from the material sent out with the ballot -- those can be read to imply that programming
languages can extend, but not restrict, theidentifier character list (10176 is, apparently, fairly clear on this matter, but that material
is not cited here)