ISO/IEC JTC 1/SC 2 N

3337/WG 2 N2059
Date: 1999-07-05

ISO/IEC JTC 1/SC 2
CODED CHARACTER SETS
SECRETARIAT: JAPAN (JISC)

DOC TYPE:

Summary of Voting/Table of Replies

TITLE:

Summary of voting on SC 2 N 3302, Subdivision Proposal on JTC 1.02.20 for8859-16, 8-bit single-byte coded graphic character sets -- Part 16: Latin No. 10

SOURCE:

Secretariat, ISO/IEC JTC 1/SC 2

PROJECT:

JTC 1.02.20

STATUS:This voting summary is forwarded to WG 3 for consideration. WG 3 isrequested to prepare a recommendation to the SC 2 Secretariat on furtherprocessing.

ACTION ID:

ACTDUE DATE:
DISTRIBUTION: P, O and L Members of ISO/IEC JTC 1/SC 2
WG Conveners and Secretariats
Secretariat, ISO/IEC JTC 1
ISO/IEC ITTF
NO. OF PAGES: 6
ACCESS LEVEL: Defined
WEB ISSUE #:057

Contact: Secretariat ISO/IEC JTC 1/SC 2 - Toshiko KIMURAIPSJ/ITSCJ (Information Processing Society of Japan/Information Technology Standards Commission of Japan)*Room 308-3, Kikai-Shinko-Kaikan Bldg., 3-5-8, Shiba-Koen, Minato-ku, Tokyo 105-0011 JAPAN
Tel: +81 3 3431 2808; Fax: +81 3 3431 6493; E-mail: kimura@itscj.ipsj.or.jp*A Standard Organization accredited by JISC

Summary of Voting on SC 2 N 3302
Vote:
Q1: Do you support the addition of the subproject to the Programme of Work of SC 2?
Yes: 15, Yes with comment: 1, No: 3
Participation:
Q2: Do you commit yourself to participate in the development of this subproject?
Yes: 5
Q3: Are you able to offer a project editor who will dedicate his/her efforts to the advancement andmaintenance of this subproject?
Yes: 2
P-member
Armenia
Australia
Austria
BelgiumBrazilCanadaChina
Denmark
Egypt
FinlandFranceGermany
GreeceIceland
India
Iran, Islamic Republic ofIreland
IsraelItaly
Japan
Korea, Rep. of
MoroccoNetherlands
NorwayPolandRomania
Russian Federation
Singapore
Slovenia
SwedenThailand
Tunisia
TurkeyUK
USA
Viet Nam
Yugoslavia

Q1

Q2

Q3

Comment

Yes

No

No

Yes
Yes
Yes
Yes
No
Yes

Yes
Yes
No

Yes
No

No

No

Yes

Yes

No

Yes

Yes

Yes

Attachment 3Yes
Yes
Yes

No
No

No
No

Attachment 4

Yes

No

No

Yes
Yes

Yes
No

Yes
No

Attachment 5

No

No

No

Attachment 6

Yes
Yes
No

No

No

Attachment 1

Attachment 2

Attachment 71

Attachment 1 - Canada
Q2: Canada - Can participate in coding related matters
Editorial:
Either remove "1-16" in the first sentence in Annex A, section A.1, or change it to "parts 1-4,9, 10, 13-16".
Reasons:
In Annex A, section A.1, the first sentence reads: "The following parts 1-16 of ... based on theLatin alphabet." Only parts 1-4 and parts 9, 10, 13-16 are listed.
In section A.2, the first sentence reads: "The following parts of ... other than the Latinalphabet". Parts 5-8, and 11 are listed here.
While it is true that all 8859-x contain Latin alphabets, the two opening sentences in A.1 andA.2 can be confusing. It's best to remove "1-16" in A.1 from the opening sentence in A.1 orto change it to "1-4 and parts 9, 10, 13-16", which is very clumsy.

Attachment 2 - Finland
Q1: In our discussions with the Swedish National Body we have come to the conclusion that
their stated reasons are equally applicable to us.

Attachment 3 - Ireland
Regarding ISO/IEC JTC1/SC2 N3302 ballot, closing date 1999-06-30:
Title: Subdivision Proposal on JTC 1.02.20 for 8859-16, 8-bit single-byte coded graphic
character sets -- Part 16: Latin Alphabet No. 10Q.1 Do you support the addition of the subproject to the programme of work of SC2?
Ireland votes Yes with Comments.
While in general Ireland does _not_ favour the addition of many new work items involving 8bit character sets, it is clear to us that this project subdivision is a natural part of Romania's
intention to deprecate the use of U+015E, U+015F, U+0162, U+0163 (or the base Latin
letters plus U+0327) for writing Romanian in favour of the preferred use of U+0218, U+0219,U+021A, U+021B (or the base Latin letters plus U+0326).
Since data encoded in ISO/IEC 8859-2 maps to the former set of characters in ISO/IEC10646, it seems a logical part of Romania's migration policy to recode data from ISO/IEC8859-2 to the new ISO/IEC 8859-16 which will map to the latter set of characters in ISO/IEC10646. It is assumed that Romania has assessed the costs of making such a migration and that
this new part of ISO/IEC 8859 should be accepted in order to assist the Romanians.

2In addition, like ISO/IEC 8859-13 does for Lithuanian and Latvian, the proposed ISO/IEC
8859-16 contains preferred Romanian quotation marks as well as the euro sign and integral
French characters, and is generally a superior 8-bit code table to meet Romanianrequirements.
Q.2 Do you commit yourself to participate in the development of this subproject?
Yes, Ireland commits to participation in the development of this subproject.
Q.3 Are you able to offer a project editor who will dedicate his/her efforts to the advancement
and maintenance of this project?
Yes, Michael Everson of Everson Gunn Teoranta, who was project editor of ISO/IEC 8859-14
and assistant editor of ISO/IEC 8859-15, has offered to prepare the text. He has been asked todo so by IRS, Institut Român de Standardizare.

Attachment 4 - Japan
Q1: It would be appreciated by Japanese national body if proceeding to NP process is
considered for this proposal. (to avoid unnecessary question from JTC 1)

Attachment 5 - Romania
Q3: Michael Everson

Attachment 6 - Sweden
1. Swedish position on Project Subdivision for Romanian code set
The Swedish NB fully recognizes the Romanian needs for correct naming of the letters S andT WITH COMMA BELOW, as different from S and T WITH CEDILLA, in character coding
standards.
However the Swedish NB has some doubts whether the proposed new part of ISO/IEC 8859,
as documented in JTC 1/SC 2 N3302, is the best solution to this character identification
problem. It appears that some further work should be performed to determine exactly how theRomanian needs are best satisfied.
The Swedish NB therefore disapproves of the proposal for a Project Subdivision according toN3302, but will – if so desired – participate in continued other work on the matter.

2. Reasons for Swedish position
There are three main reasons for the Swedish disapproval.
2.1 Existing partial solution

3

In the view of the Swedish NB, new parts of ISO/IEC 8859 should be created only when user
requirements can not be satisfied in any other way. Also it is most desirable that any new partcan be based on a stable and implemented scheme.
In the latest revision of ISO/IEC 8859-2 the Romanian character identity problem wasrecognized, and text was introduced stating that the S and T WITH CEDILLA can be used torepresent S and T WITH COMMA BELOW. This was intended as a formalization of existing
actual practice.
This 8859-2 solution will naturally cause problems if it is required to differentiate in dataprocessing between S WITH CEDILLA, as used in Turkish, and S WITH COMMA BELOW,
as used in Romanian (T WITH CEDILLA appears to not be used in any major language, anddifferentiation from T WITH COMMA BELOW should therefore not be needed).
The need to differentiate between the two S variants has previously been mentioned indiscussions. Since however the S WITH CEDILLA is not included in the proposed
Romanian new part, such differentiation is obviously not needed in Romania.

2.2 Possibility of part 2 modification
A simple solution to the identity problem would be to change the identification of the twoletters in ISO/IEC 8859-2 (and reverse the text about alternative use, stating that S and T
WITH COMMA BELOW can be used to represent S and T WITH CEDILLA).
Sweden is aware of the stated position of SC 2 to not change established code set standards
technically. An exception to this position should however be considered, since A) it appears
that the original coding was based on a misunderstanding and B) no serious effects should
result from a changed identification, the glyphs being practically identical, and Romania
being the only country directly concerned (Turkey, with the letter S WITH CEDILLA, uses
ISO/IEC 8859 part 9, not part 2).

2.3 Suitability of proposed coding scheme
It could appear natural that a new coding scheme for Romania would be based on ISO/IEC
8859-2, with the problematic S and T WITH CEDILLA exchanged for letters WITH
COMMA BELOW. This would insure an acceptable automatic "fall-back presentation" if data
was transferred from a system based on the new scheme to another still using ISO/IEC8859-2, and vice versa.
The proposed scheme is however completely different from the ISO/IEC 8859-2 (obviously
being based on the new ISO/IEC 8859-15 instead). It seems this could cause difficulties ininstallations adopting the proposed scheme, both in communication with other installations
and in "legacy applications".
Further the proposed scheme has a smaller language coverage than ISO/IEC 8859-2, notsatisfying Czech, Slovak and Sorbian needs; covering French instead. Although this matterhas naturally been carefully considered by Romania, the Swedish NB thinks it unfortunatethat the language coverage has been reduced as compared to part 2, since this may make theacceptance of the scheme more problematic.
4

The present ISO/IEC 8859-2 contains several diacritical signs, most of which should haveinsignificant - if any - use as free-standing characters. It seems that the possibility ofexchanging diacritical signs for the specifically French letters should first be considered if acompletely new part is designed, and complete coverage of French is essential.

Attachment 7 - USA
The U.S. vote is to DISAPPROVE. The reasons for disapproval are as follows:
The recommends to use ISO 10646 or ISO 8859-2, unless a marketing requirement for therepertoire of ISO 8859, part 16 is proven.

5