From: Matthew Deane [mailto:mdeane@ANSI.org]
Sent: Monday, February 10, 2003
9:49 AM
Subject:
(SC22docs.1878) SC 22 N 3541 - Summary of Voting on SC 22 N 3523, Text for
Second CD Ballot, ISO/IEC CD 15897 - Procedure for the Registration of Cultural
Elements
ISO/IEC JTC 1/SC22
Programming languages, their environments and system software interfaces
Secretariat: U.S.A. (ANSI)
ISO/IEC JTC 1/SC22 N3541
TITLE:
Summary of
Voting on SC 22 N 3523, Text for Second CD Ballot, ISO/IEC CD 15897 - Procedure
for the Registration of Cultural Elements
DATE ASSIGNED:
2003-02-10
SOURCE:
SC 22 Secretariat
BACKWARD POINTER:
N/A
DOCUMENT TYPE:
Summary of Voting
PROJECT NUMBER:
1.22.15897
STATUS:
The results of this ballot are forwarded to SC 22/WG 20 for review and
appropriate action.
ACTION IDENTIFIER:
ACT
DUE DATE:
N/A
DISTRIBUTION:
Text
CROSS REFERENCE:
SC 22 N3523
DISTRIBUTION FORM:
Def
Matt Deane
ANSI
25 West 43rd Street
New York, NY 10036
Telephone: (212) 642-4992
Fax:
(212) 840-2298
Email: mdeane@ansi.org
_____end of
cover page, beginning of document______________
SUMMARY OF VOTING ON
Letter Ballot Reference No: SC22 N3523
Circulated
by:
JTC 1/SC22
Circulation
Date:
2002-11-08
Closing
Date:
2003-02-08
SUBJECT: Summary of Voting on SC 22 N
3523, Text for Second CD Ballot, ISO/IEC CD 15897 - Procedure for the
Registration of Cultural Elements
----------------------------------------------------------------------
The following responses have been received on
the subject of approval:
"P" Members supporting this
appointment
6 (China, Czech Republic, Denmark, Republic of Korea, Norway, Switzerland)
P" Members supporting this appointment,
with
comments
1 (Germany)
"P" Members not supporting this appointment
4 (Japan, Netherlands, UK, USA)
"P" Members
abstaining
2 (Austria, France)
"P" Members not
voting
11 (Belgium, Brazil, Canada, Egypt, Finland, Ireland, DPR of Korea, Romania,
Russian Federation, Slovenia, Ukraine)
Note: O-member Sweden voted to approve
___________ end of summary, beginning on NB
comments _____________
Germany
editorial comments:
9.2.8
"but need not refer" --> "may refer"
Annex D.2
Check the printing
Technical comments:
Introduction:
Add "XML" after SGML in the introduction and
passim (of course, XML is
implied by SGML, but better be explicit)
4.4 text-file
"A file" --> "A human-readable file" (or similar)
5.5 "No modification..."
Allow versioned registrations / updates to existing
registrations,
provided all older versions are still accessible and can be uniquely
identified (to a degree, this possibility is implied by Annex A, point
14)
7.3 Identity
Create and quote a URL for registrations in Russian
9.3.7, point 9
Add note on registratiosn for the European Union (EU)
9.4 "contents of a narrative cultural specification"
General:
The list of optional clauses is fairly arbitrary.
However, all such
lists are more or less arbitrary, so no change is required at this point
beyond a note that should point out that the list of optional clauses
may be open to additions in the future.
Clause 1:
"Multilingual Sorting" --> "Multilingual Ordering"
The text should refer to ENV 13710 (as it stands, it
suggests that
there may be a European Standard in the future, but that it does not
exist already)
Clause 16:
For curiosity: In which culture are family names
capitalized
throughout?
Annex A:
The statement on copyright here conflicts with 9.3.6.
Please clarifiy
(what is really needed is not a faiver of copyright but a license to use
the registrations without charge)
Japan
There are no market needs for this registration.
Netherlands
GENERAL
1 - ISO/IEC 15897 should be a self-contained standard as much as
possible. That means that references to Posix and to 14651 should be
reduced to a minimum, and where necessary, definitions and explanations
should be added, even if this implies copying lines from Posix or
14651.
2 - The reference to CEN TC304 (see clause 8.1) should be removed.
SPECIFIC
We do not have the means to deal with every clause, but we
restrict
our comments to 9.4. The central question here is: Does this answer
what industry wants to know?
Clause 1-6:
Expand the text to explain what is really asked for. For example,
several readers told us that they had no idea what "deterministic
ordering" means. Also, a more logical sequence of clauses would
facilitate answering a questionnaire.
Clause 1:
This requires knowledge of the national alphabet, which is only made
available in clause 9. Thus put this clause first.
The question of ordering is repeated in clause 10. Why? What is the
difference? Are there two possible approaches of ordering?
Which of the two produces "culturally expected results"?
Clause 7:
This presupposes that such a thing exists. What if it does not?
Clause 9:
This question is worded in such a way that it may be interpreted by
readers quite differently, with as effect that answers are no longer
comparable, to the distress of industry.
Clause 10:
See above.
We may continue this way, but the most significant improvement to
9.4 would be that the questions should no longer put riddles to the
reader, which he cannot solve. A questionnaire in the present style
will
motivate very few people to give honest and true answers.
United Kingdom
The WG20 meeting in Tromso agreed that an alignment with the registration
procedures in 2375 should be made; this has only be partially carried through,
leaving a procedure which is far from adequate. In particular it is not
acceptable that a registered set of cultural conventions should only be checked
for conformance to some
format, we need to recognise that a set of cultural conventions could be
transnational and need to be agreed by several national bodies through some
appropriate procedure.
USA
Subject: US
Comments on CD2 Text for the Revision of ISO/IEC 15897
From: US National Body
Date: 2003-01-29
References (SC 22/WG 20
documents):
N 893, Summary of voting on CD registration and CD ballot for
ISO/IEC CD 15897. - Registration of cultural elements
N 957, Disposition of comments on CD of 15897
N 987, Information technology - Procedures for registration of cultural
elements (ISO/IEC CD2 15987:2002(E))
Notation:
A substantial number of the US comments on the first CD were not
accepted, for reasons that the US does not agree with. In addition, other US
comments that were accepted (either in actuality or in principle) have not been
adequately incorporated into the text of N 987. If text from an earlier comment
is quoted, the original number of the comment (as it appeared in N 893 or N
957) is shown, with the prefix "CD1" to distinguish it from comments
on the second CD.
Organization:
US comments consist of:
· general comments on
technical issues and on editorial issues;
· technical comments on
specific clauses; and,
· editorial comments on
specific clauses
supplemented by four appendices.
Numbering of US comments on the second CD is continuous (including
the appendices).
GENERAL COMMENTS ON TECHNICAL ISSUES
General Comment #1 - Technical
issue: On use of TR 14652
As specified in Annex E of the JTC 1 Procedures (<http://www.jtc1.org/directives/main.htm>]),
registration requires two standards:
· a technical standard ("The standard containing the definition of the classes of objects requiring registration"), and
· the procedure standard ("The standard containing the specific procedures for the JTC 1 Registration Authority to follow")
[Quotations are from Annex E.] ISO/IEC 15897 is
the procedure standard.
For a POSIX Locale or definition of a POSIX category, the
applicable technical standard is ISO/IEC 9945:2002. In other clauses, this CD2
references TR 14652.
TR 14652 is being published as a Type 1 Technical Report rather than as an International Standard because consensus could not be reached on five significant topics: LC_CTYPE, LC_MONETARY, LC_TIME, LC_XLITERATE, and REPERTOIREMAP. All of the clauses dealing with these topics are marked "controversial," i.e., there are no agreed-upon specifications for these topics.
In several places, the CD2 references one of the controversial topics in TR 14652 and sometimes specifies that the controversial topic shall be used (for example, in Clause 9.3.9). Before a controversial topic can be used, the controversy must be resolved. If this is not done, the information in registrations will be unreliable, and there will be problems with interoperability.
It is unacceptable that there would be an attempt to elevate material that is specifically labeled "controversial" in TR 14562 to normative status in ISO/IEC 15897 by specifying its use. Instead, ISO/IEC 15897 must forbid use of any of the clauses in TR 14652 that are identified as "controversial".
In comments on the "Scope" clause (which is normative), the US has supplied new text to ensure that this fundamental requirement is met.
General Comment #2 - Technical
issue: On specification of procedures
The US commented on CD1 clause 4 (now clause 7 in the CD2) as
follows;
CD1 OBJECTION #10
Section: 4 REGISTRATION AUTHORITY
Problem and Action:
It is vital that cultural specifications be reviewed by those who
represent varying viewpoints. Existing cultural specifications registered under
ISO/IEC 15897 have often been written by the editor of this IS, and often
accepted into the registry by the same person. This is a serious conflict of
interest. The rules of the registry must be written such that a person who
writes or proposes a cultural specification is not also the person who decides
whether it is accepted. Further, the registration authority must be made up of
representatives from different geographic areas and representing different
interests (for example, industry, standards committees, government agencies).
Although DKUUG is to be congratulated for volunteering to be the Registration Authority,
a group with more varied backgrounds and expertise must take on this task for
the registry to be successful.
The Editor responded in the DoC (N 957):
10. Accepted in principle. The proposed RAC will address this problem, as well as the N 945R contribution, which will be taken into account when writing the next draft.
The clauses in N 945R describing the procedures in detail have not been incorporated into the CD2. (See also specific technical comments between US comments on clauses 9 and 10.) The US is concerned about the lack of detailed information on procedures for the reasons given above.
JTC 1 Procedures (Annex E, Clause E2.6) require:
The procedure standard shall define the process for the JTC 1 Registration Authority to review and respond to applications to ensure fairness and shall define the maximum time intervals between steps of the process.
The requirement for fairness means that it is incumbent upon the Registration Authority to evaluate an application fully. The administrative material in an application can be checked by a single person, but when it comes to the technical aspects, no one person can be expected to be able to see all the technical ramifications of information in the application. This is particularly true when the Registration Authority is unfamiliar with the culture being specified. The Joint Advisory Committee must therefore be involved in the technical evaluation of each application. This parallels ISO/IEC 2375, where the Joint Advisory Committee is charged with the technical evaluation of all mappings to ISO/IEC 10646 characters included with applications for registration.
Clause E.2.6 also states:
Where the JTC 1 Registration Authority is expected to perform a technical role in determining conformance of the object to be registered to the technical standard, this role shall be defined in the procedure standard. The response to the applicant shall include information pertaining to the results of the technical review.
There is no question that a Cultural Specification registration is a technical document (particularly those that conform to POSIX requirements). Therefore, a technical review of each new or revised application is mandatory, and the complete process must be defined in the procedure standard.
The above comments also apply to revisions or replacements of existing registrations.
GENERAL COMMENTS ON EDITORIAL ISSUES
General Comment #3 - Editorial
Issue: Poor Organization
While CD2 is an improvement over CD1, many of the organizational
defects of CD1 still exist. In particular, organizational changes based on
ISO/IEC 2375 which appear in document N 945R have been disregarded.
Division of the normative general content of this standard (following Terms and conditions) should be in four basic parts:
· definition of the
agencies responsible for this standard and the procedures defined in it
· definition of the
contents of the cultural specification and layout of the registration documents
· detailed description of
the procedures for submission, review, and approval of an application for
registration
· appeal procedures and
subsequent procedures associated with a registration.
Specific US technical comments describe the necessary changes in detail.
General Comment US#4 -
Editorial Issue: Uncaught errors
From the number of spelling and grammatical errors in CD2 15897,
it is appears that the Editor did not perform spell-checking and
grammar-checking on the text. This is inadequate and unacceptable -- these
functions are readily available in modern word-processing software (including
language-specific settings). While the Editor may intend to correct such errors
at the final stage (or rely on ITTF to do so), it is preferable to catch even
editorial errors at an early stage of the technical work. The US considers that
every stage of a standard should be as correct in spelling and grammar as
possible.
General Comment US #5 -
Editorial: Titles of clauses
The titles of all clauses should follow the practice used in the
ISO/IEC Directives, Part 2. That is, they should be in lower case, except for
the first letter and any terms that are capitalized in the text of the standard
(for example, "Registration Authority").
The ISO/IEC Directives, Part 2, do not appear to have specific instructions on capitalization of the titles of clauses (the relevant clause, 5.2.2 states only: "Each clause shall have a title, placed immediately after its number, on a line separate from the text that follows it.)."
End of General Comments
SPECIFIC TECHNICAL COMMENTS
Foreword
CD2 TECHNICAL #5
The second-last paragraph of the Foreword reads:
This International Standard registers amongst other items Cultural FDCC-sets, charmaps and repertoiremaps as defined in ISO/IEC TR 14652, and POSIX Locales and POSIX Charmaps as defined in ISO/IEC 9945-2 "POSIX shell and utilities".
Delete "and repertoiremaps"
Rationale: As noted above, repertoiremaps are
identified in ISO/IEC TR 14652 as "controversial." Therefore, this
International Standard cannot register
"repertoire maps as defined in ISO/IEC TR 14652" because there is no
agreed-upon definition.
Introduction
CD2 TECHNICAL #6
First paragraph, last sentence, and Second paragraph, first sentence:
Insert "the non-controversial clauses of" before
"ISO/IEC TR 14652" in both places.
Rationale: The clauses of ISO/IEC TR 14652 marked
"controversial" shall not be used. Only the non-controversial clauses
may be used.
CD2 TECHNICAL #7
Second paragraph, second sentence:
In CD1 Objection #4, the US recommended a number of changes, all
of which were "Accepted in principle." One of these recommendations
was:
Thus, the sentence should end "...will also be freely available."
The Editor added the URL for the ISO web pages, but retained the URL for DKUUG, so that the sentence now reads:
The registration will be free-of-charge and the registered cultural elements will also be freely available on the network at the address <http://www.iso.org/mara/> (and initially at <http://www.dkuug.dk/cultreg/>).
The CD2 text now implies that the "registered cultural elements" are available at both URLs. This is incorrect. The ISO "mara" URL yields a list of registration agencies, not "registered cultural elements".
To eliminate confusion, delete both URLs, so that the sentence ends "... will also be freely available." as previously recommended.
Rationale:
(a) If the URL for the English language ISO site is given, the URL for the corresponding French language site should also be given, since French has equal status with English as an official ISO language.
(b) The URLs duplicate information that is available elsewhere:
(a)
Both ISO URLs are published in clause 7.3;
(b) The DKUUG URL is published on the two
ISO sites.
Including them here is excessive and unnecessary detail for an Introduction.
(c) [From CD1 OBJECTION #4} While DKUUG is the initial maintainer of these cultural definitions, that could change over time, so it seems inappropriate to list the address here in the Introduction.
See also comment on clause 7.3.
1 Scope
First paragraph, middle sentence:
The cultural specifications may include freeform narrative cultural conventions specifications, POSIX Locales and Charmaps conforming to ISO/IEC 9945-2, FDCC-sets, repertoiremaps and charmaps following the recommendations of ISO/IEC TR 14652, and SGML.
Make three changes to this sentence:
CD2 TECHNICAL #8
Change "ISO/IEC 9945-2" to "ISO/IEC 9945"
Rationale: A new consolidated edition has been
published.
CD2 TECHNICAL #9
Delete "repertoiremaps" and the comma and space
preceding it.
Rationale: As noted above, repertoiremaps are
identified in ISO/IEC TR 14652 as "controversial." Therefore, this
International Standard cannot register
"repertoire maps as defined in ISO/IEC TR 14652" because there is no
agreed-upon definition.
CD2 TECHNICAL #10
Insert "the non-controversial clauses of" before
"ISO/IEC TR 14652".
Rationale: The clauses of ISO/IEC TR 14652 marked
"controversial" shall not be used. Only the non-controversial clauses
may be used.
2 Field of Application
CD2 TECHNICAL #11
Delete this clause and its text.
Rationale: Essentially repeats the last paragraph
of the preceding clause.
The US recommended addition of this separate clause (as in ISO/IEC
FDIS 2375) but the ITTF rejected the separate clause when FDIS 2375 was
submitted for publication. The US regrets that it was not better informed when
it was preparing N 945 and its revision.
3 Normative references
CD2 TECHNICAL #12
N987 includes these citations:
ISO 639:1988, Code for the representation of names of
languages
ISO 639-2:1988,
Code for the representation of names of languages -- Part 2 Alpha-3 code.
Update these two citations as follows:
ISO 639-1:2002, Code for the representation of names of languages -
Part 1: Alpha-2 code.
ISO 639-2:1998, Code for the
representation of names of languages - Part 2 Alpha-3 code.
Rationale:
(a)
A new edition of Part 1 was published in 2002.
(b) The date of Part 2 is incorrect. (The
date was correct in the CD1.)
CD2 TECHNICAL #13
A new edition of the ISO/IEC standard for POSIX was published in
2002. This reference is outdated.
ISO/IEC 9945-2:1993, Information technology - Portable Operating System Interface (POSIX) -- Part 2: Shell and Utilities.
The US recommends inclusion of all of the parts of the 2002 edition of the ISO/IEC standard for POSIX:
ISO/IEC 9945-1:2002, Information technology -- Portable Operating System Interface (POSIX)
-- Part 1: Base Definitions.
ISO/IEC 9945-2:2002, Information
technology -- Portable Operating System Interface (POSIX) -- Part 2: System
Interfaces.
ISO/IEC 9945-3:2002, Information technology -- Portable Operating System Interface (POSIX) -- Part 3: Shell and Utilities.
ISO/IEC 9945-4:2002, Information technology -- Portable Operating System Interface (POSIX) -- Part 4: Rationale.
Rationale:
Previously, Part 2 contained the information about character maps,
locales, the POSIX locale, etc. That information now is in Part 1.
Also, the current Part 4 contains a small sample locale, but does not contain the Danish locale that was in POSIX.2:1993, Annex G.
CD2 TECHNICAL #14
All references in this standard must be up-to-date at each stage
of the technical work.
Rationale: ISO mandates (in the text introducing
the normative references of a standard): "For dated references, only the
edition cited applies." The most current version of standards and other
normative references must be cited at each stage, to avoid any oversights
later. The result will be up-to-date information in cultural specifications
created according to this standard.
4 Terms and definitions
4.1 locale
CD2 TECHNICAL #15
Current text:
locale
The definition of the subset of a user's
information technology environment ...See clause 2.5 of the POSIX-2 standard
for a specification of the locale file format.
Problem and Action:
This reference is obsolete. Update the text to refer to the Locale
section in ISO/IEC 9945-1:2002.
4.3 charmap
CD2 TECHNICAL #16
Current text:
charmap
A text file describing a coded character set.
See clause 2.4 of the POSIX standard for a description of the POSIX Charmap
file format...
Problem and Action:
This reference is obsolete. Update the text to refer to the
Character Set section in ISO/IEC 9945-1:2002.
4.6 cultural specification
CD2 TECHNICAL #17
The definition for "cultural specification" reads:
Either a Narrative Cultural Specification, a related POSIX Locale, a related FDCC-set, a POSIX Charmap, a ISO/IEC TR 14652 Charmap, a Repertoiremap, or another machineprocessable description of cultural conventions.
Insert the following text between
"Repertoiremap" and the comma which follows it:
(except an ISO/IEC TR 14652 Repertoiremap)
Rationale: In ISO/IEC TR 145526, 6 REPERTOIREMAP
is marked "controversial". Since there is no agreement on the
specification, an ISO/IEC TR 14552 repertoiremap shall not be used.
CD2 TECHNICAL #18
Add the term "cultural element" with definition.
Rationale: This standard "sets out the
procedures for registering cultural elements" but the term "cultural
element" is not defined.
5.4.1 Structure of the identifier
CD2 TECHNICAL #19
The current text of this clause is:
The structure of a token identifier is given in
clause 9.3.8.
The Editor needs to insert text describing the structure of the
registration number immediately before the existing text. (In particular, does
it have a maximum length, and is it zero padded?)
Rationale: The current text is inadequate because subclause 5.4, Identification of an approved registration, specifies two types of identifiers: "a unique registration number" and "one or more unique token identifiers." Both identifiers must be described.
7.2 Responsibilities
CD2 TECHNICAL #20
Clause 7.2.2
Add these two additional items at the end of the list:
- corrections and
revisions to existing registrations (as specified in clauses <designation to
be assigned>);
- withdrawal of existing registrations (as specified in
clause <designation to be assigned>).
Rationale: These are essential maintenance functions.
7.3 Identity
CD2 TECHNICAL #21
Delete the note about the "initial Registration
Authority", including the URL for the cultural register.
Rationale:
1) ISO's designated site for this information is its online database of maintenance agencies and registration authorities (available in both English and French). ISO set up this site with the specific purpose of avoiding the need to revise a standard whenever a Registration Authority changed.
2) Should DKUUG ever have to give up its duties as Registration Authority, this information would then be misleading and the standard would have to be revised. The whole purpose of giving the URL for the online database of maintenance agencies and registration authorities in the standard was to avoid revision.
3) By referring only to a URL instead of providing the name and address of the currently-designated Registration Authority, this standard is consistent with JTC1 recommendations on use of the World Wide Web.
7.4 Registration Procedure
CD2 TECHNICAL #22
Delete this clause.
Rationale:
(a) The US proposes two new clauses of the topic of registration procedures. (See New clauses on Registration procedures below.) These new clauses are more comprehensive and cover all the items in clause 7.4 (except the incomprehensible item i).
(b) Registration procedures involve several agencies, only one of which is the Registration Authority. Therefore, a clause describing registration procedures does not belong in the clause defining the Registration Authority.
US comments on specific aspects of the text of clause 7.4 of the CD2 appear in Appendix 1. Because item i is so unclear, the US comment on it is given below.
Item i
CD2 TECHNICAL #23
Current text
In the case of comments, to optionally receive text from commenters to be added to the registration as comments.
In CD1 Objection #14, the US commented:
This text is unclear. Who can submit comments? The Sponsoring Authority only? The original author(s)? Anyone? If comments are submitted, is the Registration Authority required to accept and include them, or can they reject some comments? If so, on what basis do they decide to accept or reject comments?
Information must be added here that explains who can submit comments, and what the Registration Authority can do with those comments.
The Editor responded in the DoC:
14. Noted. probably the SA, RA and the RAC could submit comments. N 945R will be taken into account.
N 945R has not been taken into account. Except for a grammatical correction, the text is unchanged. The Editor has failed to add information to the CD to answer the questions raised by the US in CD1 OBJECTION #14 and also in N 945R (Who are these "commenters"? Anyone who chooses to send the RA a comment? And how is such a comment evaluated for accuracy?).
With respect to the Editor's surmise in the DoC, why would the SA be supplying comments? Why would the RA be supplying comments? (The RA would be giving specific instructions to the SA, possibly based on comments from reviewers.)
Clause 7.4 Registration Procedures (d) shows that the RA receives comments and forwards them to the SA for action. Perhaps one can infer that the comments in item d are comments from the SC22 and RA-JAC reviews (described in item c). But the source and processing of the comments in item i are a total mystery.
8.1 Identity [of the Sponsoring Authority]
CD2 TECHNICAL #24
Current list of who may submit applications:
a) Any Member Body or Associated Member Body of CEN or ISO/IEC JTC1, for applications related to the territories for which they have authority;
b) CEN/TC304 for
applications related to the region of Europe;
c) ISO/IEC JTC 1 and its Subcommitees and
Working Groups, for any applications;
Delete this list and substitute:
a)
ISO/IEC JTC 1 and its Subcommittees and Working Groups, for any applications;
b) CEN/TC304 for applications
pertaining to Europe;
c) Any National Body or liaison
organization of ISO/IEC JTC1, for applications limited to the territory or
territories for which they have authority;
d) Any Member Body or Associated Member Body of CEN for applications limited to the territory or territories for which they have authority;
Rationale:
The restructuring keeps information pertaining to ISO/IEC JTC 1
separate from information pertaining to CEN.
"National body" (not "Member body") is the
preferred ISO and JTC 1 term (see, for example, clause 2.2.3 in the JTC 1 Procedures).
8.2 Responsibilities
CD2 TECHNICAL #25
Replace item a
to receive applications concerning Cultural Specifications, eg. from firms or organizations in the country, or national experts;
with the following text
to receive applications concerning Cultural Specifications from organizations, firms or experts operating in the area over which the Sponsoring Authority has jurisdiction.
Rationale: The current wording is inapplicable to CEN/TC 304, which is not responsible for a particular country.
CD2 TECHNICAL #26
New item
Insert the following text as a new item immediately before item d:
if any material in an application is under copyright, to include copyright clearance from the copyright holder in the application;
Rationale: If the Sponsoring Authority is submitting material under copyright, the SA must obtain copyright clearance for it. The SA may require the organization or individual initiating the application to provide the copyright clearance. This item replaces the clause on copyright clearance in N 945R.
Note this amplifies the requirement in clause 9.3.6
A written application shall accompany the Cultural Specification and be signed by authorized personnel on behalf of the contributing organization. It shall release copyrights of the contributed sources.
and makes it clear that the Sponsoring Authority is obligated to obtain copyright clearance for any copyrighted material that is included in the application.
# Source of information
CD2 TECHNICAL #27
Add new clause and text to be supplied by the Editor.
Rationale: There is an implied assumption that the
Sponsoring Authority is also source of the information in the application. This
may not always be true (see clause 8.2, item a). The two need to be
distinguished.
# Copyright clearance
Dealt with in new item added to clause 8.2 that makes the Sponsoring Authority responsible for obtaining copyright clearance.
Clause 9 Rules for applications
CD2 TECHNICAL #28
The US
strongly recommends that this clause be
restructured as shown in Appendix 2.
Additional US comments on the text of clause 9 (below) refer to
individual clauses by their CD2 numbers.
Clause 9.1 Types of cultural Specifications
CD2 TECHNICAL #29
Current text:
Type 4 is for Repertoiremaps defined in this International Standard (clause 9.3.9) and in ISO/IEC TR 14652.
Change this reference to:
Type 4 is for Repertoiremaps as defined in ISO/IEC TR 14652.
Rationale: Repertoiremaps are listed as
controversial in TR 14652 and shall not be elevated to normative status in this
standard.
Clause 9.2 Relations between registration types
Clause 9.2.2
CD2 TECHNICAL #30
Current text:
9.2.2. The POSIX Locale shall specify appropiate aspects of a Narrative Cultural Specification in formal POSIX syntax. The POSIX Locale shall refer to the Repertoiremap being used, and should also list a number of POSIX Charmaps that it can use.
Revise the second sentence as follows:
The POSIX Locale should list one or more POSIX Charmaps it can
use.
Rationale:
Since Repertoiremaps are a controversial part of TR 14652, it is
inappropriate for this standard to say that they "shall" be used,
thus elevating them to normative status.
Also, while this text says one should list "a number of POSIX Charmaps", the examples in Annex G only list one each; if the examples don't even bother to list "a number," that shouldn't be the recommendation here.
Clause 9.2.5
CD2 TECHNICAL #31
Current text:
In the case of a TR 14652 FDCC-set, or other machine-parsable cultural specification, it shall specify in formal syntax some aspects of a Narrative Cultural Specification, and shall refer to a corresponding Narrative Cultural Specification. In case of a TR 14652 FDCC-set it shall refer to the Repertoiremap being used, and should also list a number of Charmaps that can be used.
Add this sentence at the end of the clause:
A TR 14652 Repertoiremap shall not be used.
Rationale: In ISO/IEC TR 145526, 6 REPERTOIREMAP
is marked "controversial". Since there is no agreement on the
specification, an ISO/IEC TR 14552 repertoiremap cannot be used.
Clause 9.2.6
CD2 TECHNICAL #32
Current text:
In case of a ISO/IEC TR 14652 Charmap, or other machine-parsable character set descriptions it shall specify aspects of a Narrative Cultural Specification or an FDCC-set that relate to coded character sets. In case of a Charmap it shall refer to the Repertoiremap being used, but need not refer to the FDCC-set nor the Narrative Cultural Specifications using it.
Add this sentence at the end of the clause:
A TR 14652 Repertoiremap shall not be used.
Rationale: In ISO/IEC TR 145526, 6 REPERTOIREMAP
is marked "controversial". Since there is no agreement on the
specification, an ISO/IEC TR 14552 repertoiremap cannot be used.
Clause 9.3 Rules for Cultural Specifications
9.3.1
CD2 TECHNICAL #33
Current text:
. . . A Narrative Cultural Specification may alternatively be submitted on white paper of the approximate size 297 * 210 mm, with margins of no less than 20 mm, or one of the approved document formats of ISO/IEC JTC 1,. . .
In CD1 OBJECTION #21, the US commented:
What is the rationale for specifying the paper size here? Unless there is a good reason, this should be removed.
The Editor responded in the DoC:
21. Not accepted. The RA has a responsibility to be able to print the registry.thus all data must fit on a paper size that the RA can handle. The RA will deliver such prints on A4, which is the common papersize for such things.
Additional comments on clause 9.3.1:
1) The reliance on paper conflicts with clause 7.11.3 Electronic Document Distribution in the JTC 1 Procedures, which states:
Document distribution within JTC 1 shall be done to the maximum extent possible using the World Wide Web. The details of this policy are contained in Annex H.
2) For the convenience of the reader, the source for the "approved document formats of ISO/IEC JTC1" should be cited. Is this Annex HA Text Area for A4 and North American Paper Sizes in the JTC 1 Procedures?
3)
Why say "approximate" size, and why describe the actual paper size?
Why not say "A4" paper?
4) A 20 mm margin at the bottom of
the page is in conflict with Annex HA of the JTC 1
Procedures, where the minimum for the bottom margin
is 28 mm. Does the stated requirement for 20 mm margins apply only to the right
and left margins? The minimum margins specified in Annex HA are: Top 13 mm,
Bottom 28 mm, Left 20 mm, Right 13 mm, although more generous symmetrical
margins are allowed.
9.3.2.
CD2 TECHNICAL #34
In CD1 OBJECTION #22, the US commented:
Section 6.2 contains a very terse list of items that could appear in a cultural specification. The description of these very terse items appears in the informative Annex G. This makes the document extremely difficult to use. When most readers see items like "Inflection" or "Coding of national entities" with *NO* further explanation, they will have no idea what is intended. They can go to Annex G, but why is the information there instead of where it is originally referenced?
The explanation of the items allowable in a cultural spec should appear in Clause 6 along with the items themselves.
This comment was accepted by the Editor. The text of Annex G has been incorporated as 9.4, with a very minor change in the introductory paragraph. However, the intent of the US comment was to eliminate double look-up. Instead of checking Annex G, the user must now check clause 9.4. The problem persists.
Additional comments:
1) The numbered lists in clause 9.3.2 replicate the fuller information in clause 9.4. This is unnecessary. The US proposes that these lists be eliminated. We will propose substitute text to improve the organization of clauses 9.3 and 9.4.
2) The US notes that the text in Annex G was informative (as noted in Objection #22). By its incorporation into the technical content of the standard, its status has been changed to normative. This important change should have been noted in the Disposition of Comments.
Clause 9.3.2, last two
paragraphs
CD2 TECHNICAL #35
Current text:
The format of the POSIX Locale and Charmap sources shall be conformant to ISO/IEC 9945-2, or for POSIX Locales the technique specified in Annex E.
The format of the Repertoiremap shall be conformant to clause 9.3.9.
Change the text to:
The format of the POSIX
Locale and Charmap sources shall be conformant to ISO/IEC 9945-1:2002.
A possible format of the Repertoiremap is described in clause
9.3.9.
Rationale
(a)
The reference to 9945 is obsolete.
(b) The US objects to the technique
specified in Annex E; it must not be part of this standard (see CD2 TECHNICAL
OBJECTION #37).
(c) As noted before, the TR 14652 Repertoiremap is controversial and shall not be a normative part of this standard.
Clause 9.3.3
CD2 TECHNICAL OBJECTION #36
Current text:
The POSIX Locale shall define all standard categories (for example by copying categories of a standard POSIX Locale; examples are given in annex F). The FDCC-set shall define all standard categories (for example by copying categories of a standard "i18n" FDCC-set; examples are given in annex F).
Substitute this text for the current text:
The POSIX Locale and
FDCC-set shall define all standard categories.
Individual categories may be copied from another Locale or
FDCC-set. See Annex G for examples.
Rationale: Annex F contains information on the "reorder-after" construct; not examples of POSIX locales or FDCC-sets. Annex G contains sample POSIX locales, but not FDCC-sets.
Clause 9.3.4
CD2 TECHNICAL OBJECTION #37
Current text:
The coded character set of ISO/IEC 646 International Reference Version (ISO 2375 registration number 6) shall be used to represent text for the submitted files. For enhanced network portability it is recommended that only the invariant part of ISO/IEC 646 (ISO 2375 registration number 170), which contains 83 graphical characters (including space), be used...
The US objected to this during the previous
ballot, and we renew our objection.
Remove the second sentence "For enhanced network
portability..."
Rationale: Both the 1993 and 2002 versions of the
POSIX standards allow all graphic characters in ISO 646 IRV, and there is no
reason to be more restrictive in this standard. In the DoC to our previous
objection, the Editor's response was:
Not accepted. This is
aligned with other specs in the field.
However, it is not aligned with the standard which invented
POSIX locales and charmaps. This difference is egregious and unacceptable.
The US also notes that the Editor provided no information about the "other specs in the field" which he used to justify the rejection.
CD2 TECHNICAL #38
Add this sentence at the end of the clause, following
"...character names defined in a Repertoiremap shall be used."
A TR 14652 Repertoiremap shall not be used.
Rationale: In ISO/IEC TR 145526, 6 REPERTOIREMAP
is marked "controversial". Since there is no agreement on the
specification, an ISO/IEC TR 14552 repertoiremap cannot be used.
Clause 9.3.7, second and third
paragraphs
CD2 TECHNICAL OBJECTION #39
Current text:
For Types 1, 2, and 5, Narrative Cultural Specifications, POSIX Locales, and FDCC-sets and other formal descriptions of cultural conventions: . . .
For Types 3, 4, and 6, POSIX Charmaps, Repertoiremaps, and TR 14652 Charmaps and other formal descriptions of character sets: . . .
Revise the text as follows:
For Types 1, 2, and 5, Narrative Cultural Specifications, POSIX Locales, and Machine-parsable cultural specifications: . . .
For Types 3, 4, and 6, POSIX Charmaps, Repertoiremaps, and Machine-parsable coded character set specifications: . . .
Rationale: The descriptive names of Types 1, 2, 3, and 4 here match the type names in Section 9.1, but those for Types 5 and 6 do not. They must.
Clause 9.3.7, third paragraph
CD2 TECHNICAL #40
Add this sentence as a separate line between "10. Suggested
Charmap or Repertoiremap or other name" and "All applications shall
contain information on these items:"
A TR 14652 Repertoiremap shall not be used.
Rationale: In ISO/IEC TR 145526, 6 REPERTOIREMAP
is marked "controversial". Since there is no agreement on the
specification, an ISO/IEC TR 14552 repertoiremap cannot be used.
Clause 9.3.7, third paragraph
from end (begins "Note:")
CD2 TECHNICAL #41
Change "U0020..U007E" to "U+0020..U+007E"
Rationale: ISO/IEC 10646 conventions.
Clause 9.3.7, last paragraph
CD2 TECHNICAL #42
The final paragraph of clause 9.3.7 states:
Annex A specifies a form to be filled out for each Cultural Specification; Annex B gives an example of a completed form."
There is no indication that Annex A is required, although the normative attribute of Annex A suggests this. The final paragraph should be reworded as follows:
The form in Annex A shall be included as part of an application for registration of a Cultural Specification. Annex B gives an example of a completed form.
Clause 9.3.8, third and sixth
paragraphs
CD2 TECHNICAL #43
"National Standardization Organization" is an undefined
term. Does it mean a "National Body" (per ISO and JTC 1 terminology),
or is it intended to include additional organizations that are involved with
standardization?
Clause 9.3.9
CD2 TECHNICAL OBJECTION #44
Current text:
POSIX Locale, FDCC-set and Charmap sources shall be specified in a way that is independent of coded character sets, using character names. Relation between the character names and characters shall be specified via a Repertoiremap table, giving the character name and the ISO/IEC 10646 short character ID in the form of Uxxxx or Uxxxxxxxx, and optionally the long ISO/IEC 10646 character nam