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 name. It is recommended to use, whenever possible, character names specified in ISO/IEC 9945-2:1993 Annex G. The character name and the ISO/IEC 10646 canonical encoding are each surrounded by angle brackets <>, and the fields shall be separated by one or more spaces or tabs on a line. If a right angle bracket or an escape character is used within a name, it shall be preceded by the escape character. The escape character can be redefined from the default reverse solidus (\) with the first line of the Repertoiremap containing the string "escape_char" followed by one or more spaces or tabs and then the escape character.
Revise the text as follows:
POSIX Locale, FDCC-set and Charmap sources can be specified in a way that is independent of coded character sets, using character names. Relation between the character names and characters can 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 name. The character name and the ISO/IEC 10646 canonical encoding are each surrounded by angle brackets <>, and the fields are separated by one or more spaces or tabs on a line. If a right angle bracket or an escape character is used within a name, it should be preceded by the escape character.
Rationale: There are several problems with this clause:
(a) Since the previous ballot version of this section, TR 14652 has been finalized, but much of it, including the Repertoiremap section has been designated as controversial. Since WG20 did not reach agreement on the status and syntax of Repertoiremap in TR 14652, it is not acceptable to elevate it to normative status in this standard.
(b) The previous U.S. objection to referring to the character names in ISO/IEC 9945-2:1993 Annex G was rejected with this comment: "Not accepted. There is a reason, namely that you then can reuse a lot of data." Although we do not consider this a compelling rationale, this reference has become obsolete since the CD1 was balloted. ISO/IEC 9945:2002 does not contain an Annex G with the character names referenced here. In ISO/IEC 9945-4:2002 (Rationale), there is a short sample locale, but it does not use the vast majority of the names from the 1993 version of Annex G. Since POSIX no longer includes these character names, this standard cannot do so.
(c) The information about how to redefine the escape character is inappropriate. The Editor of this standard chooses not to use the default escape character that POSIX defines, and he is free to do so. But it is not appropriate in this syntax definition to tell others how to use the same non-default escape character that he has chosen.
Clause 9.4 Contents of a Narrative Cultural Specification
Introductory paragraph, first
and second sentences:
CD2 TECHNICAL OBJECTION #45
Current text:
The contents of the Narrative Cultural Specification is described in some detail in the following. it builds on information from the POSIX Shell and Utilities standard (ISO/IEC 9945-2) and the Nordic Cultural Requirements on Information Technology Summary Report.
Revise the text as follows:
The contents of the Narrative Cultural Specification are described in some detail in the following clauses. The specification builds on information from the POSIX Base Definitions standard (ISO/IEC 9945-1:2002) and the Nordic Cultural Requirements on Information Technology Summary Report.
Rationale: The POSIX reference is out-of-date, there is a grammatical error, and a typo.
Introductory paragraph, third
and fourth sentences:
CD2 TECHNICAL #46
In CD1 OBJECTION #44, the US proposed changing the sentence
. . Clauses 1 to 6 are related to POSIX and the narrative description should be accompanied by a corresponding POSIX Locale specification.
to
Clauses 1 through 6 are related to POSIX.
The proposed change was partially accepted; the fourth sentence
was added. However, the text which the US considered inconsistent with other
parts of this standard was not removed. The text now reads:
Clauses 1 to 6 are related to POSIX and the narrative description should be accompanied by a corresponding POSIX Locale specification. If a POSIX locale is submitted, it is desirable that it be accompanied by a related narrative cultural specification.
Strike these two sentences and replace them with this text.
Clauses 1 to 6 are related to POSIX. When a POSIX locale is submitted, it should be accompanied by a corresponding narrative cultural specification.
Note that "is desirable" is not needed because use of "should" is specified in Table G.2 of Annex G Verbal forms for the expression of provisions in ISO/IEC Directives, Part 2: Rules for the structure and drafting of International Standards:
The verbal forms shown in Table G.2 shall be used to indicate that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others, or that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited.
Clause 3: Numeric formatting
CD2 TECHNICAL OBJECTION #47
Current text:
Here it is described how numbers are keyed in and formatted,. . .This is a POSIX category.
Delete current text and substitute:
This clause describes how numbers are formatted, including the format of the decimal point and the thousands separator. This is a POSIX category.
Rationale:
POSIX contains no information about how numbers are "keyed
in", and neither of the sample cultural narratives in this document
include such info, either. If information about keying in is needed, it should
be moved to Clause 20 Numbering, ordinals and measuring
systems, since it isn't part of this POSIX category. (See comment
on Clause 20 for proposed text addressing how numbers are "keyed
in".)
Clauses 7 through 32
CD2 TECHNICAL #48
For the guidance of users, the US recommends that the word
"(Optional)" be added at the end of the heading for each of these
clauses. (Clause 9.3.2 indicates, by the use of "may", that clauses 7
through 32 are optional.)
Rationale: Such guidance is particularly important now that the material from CD1 Annex G has been raised to normative status.
See Appendix 3 for US technical and editorial comments on the optional (non-POSIX) clauses. Headings for the individual clauses show the modification recommended above.
New clauses on Registration procedures
CD2 TECHNICAL #49
Minimum requirements:
1) Make clause 7.4 Registration Procedure into a top-level clause and move it so that it immediately precedes clause 10 Appeal procedures.
2) Expand the text of clause 7.4 Registration Procedure to provide a complete description of registration procedures. In particular, distinguish between procedures carried out prior to approval of an application for registration and the procedures that follow approval.
3) Change its title to Registration procedures.
Rationale:
(a)
Relocating clause 7.4 brings all procedures together in successive clauses.
(b) This is a procedural standard, so
should specify procedures completely and clearly.
(c) Title change for consistency with the
title of clause 10.
Alternative preference:
The US would prefer to see the specification of the registration
procedures divided into two separate top-level clauses. These clauses should
immediately precede clause 10 Appeal
procedures. The individual clauses are specified in
the next two comments.
Rationale (in addition to items a-c above): To make the standard easier to use.
CD2 TECHNICAL #50
This comment describes the first clause preferred by the US.
Insert a new clause with the title Initial registration procedures preceding clause 10 Appeal procedures.
The following proposed text is from clause # Registration procedure in N 945R. "x" indicates the
number that identifies this clause as a whole. All items in clause 7.4 Registration Procedure are covered in the proposed text, except
for item i (see CD2 Technical Comment on this item above).
<begin proposed text>
x.1 The Sponsoring Authority shall prepare an application for
registration according to clause 9.
x.2 The Sponsoring Authority shall submit an application for
registration of a cultural specification to the Registration Authority.
x.3 The Registration Authority shall examine
each application received. It shall ascertain that
- The applicant is a Sponsoring Authority as identified in clause
#. The RA shall reject applications for registrations which come from sources
other than the Sponsoring Authorities as defined in clause #. The Registration
Authority may refer the applicant to an appropriate Sponsoring Authority if one
can be identified.
- The proposed cultural specification is not
identical to one already registered.
If the application fails to meet either of these requirements, the
application shall be rejected.
When requested by the RA, the RA-JAC may provide an opinion on
whether an application satisfies these requirements.
x.4 The Registration Authority shall also ascertain that
- The application for registration is legible and meets the
presentation requirements of this international standard. See clause
<XXX>.
- The application includes the elements required
from the Sponsoring Authority for the cover page. See clause <XXX>.
- The application for registration includes any required copyright
permissions and endorsements. See clause <XXX>.
If the application for registration fails to meet any of these
requirements, the Registration Authority shall inform the Sponsoring Authority
of the changes needed to meet the requirements.
x.5 The Registration Authority shall submit the application to the RA-JAC for the technical review. The RA-JAC shall ascertain that
- The application is technically in accordance
with this International Standard.
- The application for registration includes the required
description of the cultural specification. See clause <XXX>.
x.6 The RA-JAC shall report the results of its evaluation to the
Registration Authority and shall describe any technical concerns with the
proposed registration.
x.7 The Registration Authority shall inform the Sponsoring Authority of any changes needed to satisfy the concerns of the RA-JAC.
x.8 After an application for registration has passed its review by the Registration Authority and by the RA-JAC, the Registration Authority shall circulate the application to the members and liaison organizations of the subcommittee responsible for maintaining this standard for a three-month information and comment period.
x.9 The Registration Authority shall consider all comments received. The Registration Authority shall request the RA-JAC to provide expert advice on the technical comments. The Registration Authority may incorporate comments resulting from the review specified in clause <x.8> into the final registration.
x.10 The Registration Authority shall approve or
reject the application for registration.
x.11 The Registration Authority shall process approved
applications in accordance with clause <Y>.
x.12 When an application for registration is rejected, the
Registration Authority shall inform the Sponsoring Authority and provide the
reason for the rejection.
<end proposed text>
CD2 TECHNICAL #51
This comment describes the second clause preferred by the US.
Insert a new clause with the title Processing of an approved application between the
new clause Initial registration
procedures and clause 10 Appeal procedures.
The following proposed text is primarily from clause Y. Processing of an approved application in N 945R. "y" indicates the number that identifies this clause as a whole.
<begin proposed text>
Following approval of an application for registration, the
Registration Authority shall:
y.1 Assign a new Cultural Specification identifier as follows:
- Identifiers shall be allocated in ascending order. This
allocation shall only be made immediately prior to publication of the
registration, that is, after completion of all procedural steps.
- No identifiers shall be reserved for future
registration applications.
- An identifier, once allocated to a registration, shall never be
re-allocated for another registration.
y.2 The Registration Authority may also assign one or more token
identifiers to the approved registration.
- If the Cultural Specification is identical to one already
registered, the new token identifiers shall be added to the existing
registration, and the addition shall be noted in the version history of that
registration;
y.3 The Registration Authority shall note the
date of approval in the registration.
y.4 The Registration Authority shall publish the approved
registration in the ISO/IEC 15893 register.
y.5 The Registration Authority shall notify the Sponsoring
Authority of the publication of the registration.
y.6 The Registration Authority shall announce publication of the
registration to subcommittee responsible for maintaining this standard.
<end proposed text>
10.1 Appeals against rejection
CD2 TECHNICAL OBJECTION #52
Current text:
The Registration Authority shall accept an appeal from the Sponsoring Authority against rejection of an application, but only for this reason:
- disagreement with the Registration Authority on whether the application meets the technical or administrative requirements for a registration in clause 9.
Reword as:
If the Registration Authority rejects an application, the Sponsoring Authority may appeal that rejection based only on whether the application meets the technical or administrative requirements for a registration as described in clause 9.
Rationale: Unclear text;
Note: This is a revision of what the US originally asked for. The
wording in 2375 was an attempt to change the wording of the earlier edition as
little as possible.
Appeals against registration
CD2 TECHNICAL #53
Clause 7.2 of the first CD addressed objection by a Member Body to
forthcoming publication of a registration. There is no corresponding clause in
CD2 15897.
To remedy this oversight:
1)
Renumber clauses 10.2 through 10.4 as 10.3 through 10.5.
2) Insert clause 10.2 Appeals against registration with the following text
and numbering:
<begin text>
10.2.1 The Registration Authority for shall accept an appeal from
the subcommittee responsible for the maintenance of this International Standard
when any Member Body objects to the forthcoming publication of a registration
by the Registration Authority.
10.2.2 The Registration Authority shall accept appeals from the subcommittee responsible for the maintenance of this International Standard for the following reasons only:
1) disagreement with the Registration Authority on whether the application meets the technical or administrative requirements for a registration in clauses <as specified in clause 9>.
2)
disagreement with the Registration Authority on whether the application matches
an existing registration.
3) disagreement on the correctness
of some of the information in the cultural specification of the application.
<end text>
10.3 Procedure for filing an appeal
CD2 TECHNICAL #54
Make the following changes which appear in N 945R but were not
included in CD2 15897:
First line: After "registered mail", insert a comma
followed by this text:
facsimile, or electronic mail
Rationale: Consistent with JTC 1 recommendation in
clause 7.11.2 Use of Electronic
Messaging in Procedures for the
technical work of ISO/IEC JTC 1).
First bullet: Change "90" to
"30"
Second bullet: Change "90" to "30"
Rationale: These are the periods in ISO/IEC 2375:
200x.
10.4 Resolution of an appeal
CD2 TECHNICAL #55
Most of clause 7.5 Resolution
of an appeal was incorporated into the CD2, but
clause 7.5.3 (dealing with resolution of an objection by a National Body to
forthcoming publication of a registration) was omitted. To correct this error:
1)
Renumber clause 10.4.3 as 10.4.4
2) Insert clause 10.4.3 and the
following text (from clause 7.5.3 in N 945R)
<begin text>
If four-fifths of the members of the RA-JAC consider the appeal
from the subcommittee responsible for maintaining this standard to be
administratively or technically justified, the Registration Authority shall
disapprove the registration application. If the appeal is based on clause
10.2.2, item 3 (correctness of some of the information) and the Sponsoring
Authority modifies the questionable information to the satisfaction of the
appealing party and the RA-JAC, then the Registration Authority shall register
the corrected cultural specification without repeating the registration
process.
<end text>
CD2 TECHNICAL #56
Clause 10.4.4 (= 10.4.3 in CD2 15897):
Make the following two changes to this clause:
1) Delete the following text
(including the misspelling of "receipt"):
by the Registration Authority within 90 days
after the reciept of an appeal
Rationale: Communication with the "P-members
of the subcommittee responsible for the maintaining of this International
Standard" is the responsibility of the subcommittee's Secretariat. (The
Registration Authority is, of course, responsible for making arrangements with
the Secretariat.)
2) Change this
text:
to decide according to its voting procedures.
to
according to the Procedures
for the technical work of ISO/IEC JTC 1.
Rationale: Since this is a JTC 1 standard, JTC 1
procedures apply. The same wording appears in ISO/IEC 2375:200x.
Note that the recommended wording in N 945R:"for vote
according to the Directives for technical work of ISO/IEC" is taken from
an earlier stage of ISO/IEC 2375:200x.
11 The Registration Authority's Joint Advisory Committee
CD2 TECHNICAL #57
Relocate this clause immediately after clause 8 Sponsoring Authority.
Rationale: Brings all agencies defined by this
standard together.
Note: For the convenience of reviewers, other changes to the text of clause 11 of the CD2 are described here.
Clause 11.1
CD2 TECHNICAL #58
Make the following changes to this clause:
1) Add this title:
Membership
Rationale: For consistency with changes to clauses
11.2 and 11.3.
2) Delete the last paragraph:
The Registration Authority may request the RA-JAC to provide expert technical advice on comments.
Rationale: Does not belong in a clause specifying the composition of the RA-JAC. The responsibilities of the RA-JAC are listed in clause 11.3.
Clause 11.2
CD2 TECHNICAL #59
Add this title to clause 11.2:
Appointment
Rationale: For consistency with other clauses
describing agencies (for example, 7 Registration
Authority).
Clause 11.2, first paragraph
CD2 TECHNICAL #60
Current text:
The subcommitee responsible for maintaining this standard shall appoint the members of the RA-JAC, except for the RA representative, which is appointed by the RA. The subcommitee shall appoint or confirm the members of the RA-JAC at its plenary meetings.
N 945R says to delete this phrase:
except for the RA representative.
because there is no indication of who appoints the RA
representative to the Joint Advisory Committee. The resulting paragraph then
specifies that all members of the Joint
Advisory Committee (including the individual who represents the RA) are appointed
by the subcommittee responsible for maintaining this standard (i.e., by SC22).
The Editor did not delete the phrase and added a
clarification, so that the corresponding text in the CD2 now reads:
except for the RA representative, which is
appointed by the RA.
This new text is unacceptable to the US for the following reasons:
a) It conflicts with the provisions of the second paragraph of this clause, which clearly states that the subcommittee (i.e., SC22) determines the members of the Joint Advisory Committee:
The subcommitee shall appoint or confirm the members of the RA-JAC at its plenary meetings.
b) It conflicts with the provisions of ISO/IEC 2375:200x. It was WG20's intent to model the administrative aspects of this revision of ISO/IEC 15897 on the thoroughly reviewed text of ISO/IEC 2375:200x.
c) It is unnecessary. The wording "representative of the Registration Authority" was used in clause 11.1 to provide flexibility in case it is not possible for the person carrying out the duties of the Registration Authority to attend meetings of the Joint Advisory Committee. It is essential for the Registration Authority to be represented at these meetings. The expectation is that the person carrying out the duties of the Registration Authority would normally be chosen by the supervisory body for this standard (i.e., SC22) for appointment as the "representative of the Registration Authority".
Clause 11.2, second paragraph
CD2 TECHNICAL #61
Insert this text after "subcommittee"
responsible for maintaining this standard
to indicate explicitly which subcommittee makes the appointments.
Clause 11.3
CD2 TECHNICAL #62
Add this title to clause 11.3:
Responsibilities
Rationale: For consistency with other clauses
describing agencies (for example, 7 Registration
Authority).
CD2 TECHNICAL #63
Keep this introductory text "The responsibilities of the
RA-JAC shall be as follows:" and substitute the following text (based on
#.4 in N 945R and clauses 11.1 and 11.3 of CD2) for the remainder of the
clause.
<begin text>
- to determine whether an
application for registration meets the technical requirements of clause 9;
- to provide expert technical
advice on comments if requested by the Registration Authority;
- to consider and vote on
appeals received by the Registration Authority;
- to act as a mediator between
the Registration Authority and the appealing party, or parties.
In addition, the RA-JAC may added comments to a registration.
<end text>
Additional clauses
Insert 4 new clauses before Annex A. The clauses are described separately below. They are numbered 12 - 15, since the clause 11 is the last clause in the main text of CD2.
New clause: 12 Corrections
CD2 TECHNICAL #64
Add a new clause with the title:
Corrections
and the following text (from the corresponding clause in N 945R):
<begin text>
12.1 The Registration Authority for ISO/IEC 15987 in conjunction
with the Sponsoring Authority shall correct material errors to the information
included in a registration, for example typographical errors, as soon as
detected.
12.2 The Registration Authority shall add the date of the correction to the corrected pages, add the date and reason for the change to the cover sheet, and publish the new corrected pages of the registration.
12.3 The Registration Authority shall notify the subcommittee responsible for maintaining this standard and the Sponsoring Authority that a registration was corrected with the nature of the correction and the date.
<end text>
Note that this clause conflicts with the idea expressed in clause 5.5 that a new registration is required to make a "correction", presumably even a typographic correction.
New clause: 13 Revisions
CD2 TECHNICAL #65
Add a new clause with the title:
Revisions
and the following text (from the corresponding clause in N 945R):
<begin text>
13.1 In general, no changes to the content of a registration are
permitted, as this would be contrary to the principles on which the
registrations are based.
13.2 When a new registration application is based on an existing registration, then the Registration Authority shall create a new registration. The Registration Authority shall also add cross-reference notes to the two registrations.
<end text>
New clause: 14 Additions to an existing registration
CD2 TECHNICAL #66
Add a new clause with the title:
Additions to an existing registration
and the following text (from CD2, clause 7.4, item f):
<begin text>
When a Cultural Specification submitted for registration is
identical to one already registered, the token identifier(s) for the
application shall be added to the existing registration;
<end text>
The Editor is requested to supply text describing the procedures to be followed in these situations:
1)
A Sponsoring Authority wishes to augment an approved registration which it
submitted; or
2) A Sponsoring Authority wishes to
augment an approved registration which was submitted by another Sponsoring
Authority.
New clause: 15 Withdrawal
CD2 TECHNICAL #67
Add a new clause with the title:
Withdrawal
and the following text (based on the corresponding clause in N
945R):
<begin text>
15.1 Withdrawal is a formal declaration by which the Sponsoring
Authority informs the Registration Authority that it withdraws its support of a
registration application or of all or part of an existing registration that it
has sponsored.
15.2 Such a declaration may, but need not, be
accompanied by a statement of the reasons for the withdrawal.
15.3 Withdrawal of an application for registration
15.3.1 When the Registration Authority is notified, it shall take
no further action to process the application.
15.3.2 If the application for registration is being circulated for
comment according to clause x.8 (in Initial
registration procedures), the Registration Authority shall
notify the members of the subcommittee that the application has been withdrawn
by the Sponsoring Authority.
15.4 Withdrawal of an entire existing
registration
15.4.1 After withdrawal, the registration shall remain in the
register and continue to be identified by the allocated numeric identifier.
15.4.2 After the date of withdrawal, the Registration Authority shall issue a new cover page for the registration and shall note on it that the registration has been withdrawn by the Sponsoring Authority. If the Sponsoring Authority has given a reason for the withdrawal, this may be noted in the registration.
15.4.2 After the date of withdrawal, the Registration Authority shall issue a new cover page for the registration and shall note on it that the registration was withdrawn by the Sponsoring Authority and give the date of withdrawal. When the Sponsoring Authority has given a reason for a withdrawal, the reason may be noted in the registration.
15.4.3 The Registration Authority shall inform the subcommittee responsible for maintaining this standard interested parties of the withdrawal of a registration.
15.5 Withdrawal of part of an existing
application
15.5.1 After withdrawal, the registration (including the withdrawn
part) shall remain in the register and continue to be identified by the
allocated numeric identifier.
15.5.2 After the date of withdrawal, the Registration Authority shall issue a new cover page for the registration and shall note on it the part(s) of the registration that were withdrawn by the Sponsoring Authority. The Registration Authority shall also annotate a withdrawn part to show that it was withdrawn and give the date of withdrawal. When the Sponsoring Authority has given a reason for a withdrawal, the reason may be noted in the registration.
15.4.3 The Registration Authority shall inform the subcommittee responsible for maintaining this standard interested parties of the withdrawal of a registration.
<end text>
Annex A Application form for a Cultural Specification
Items 8, 9 and 10
CD2 TECHNICAL OBJECTION #68
Current text:
For Narrative Cultural Specifications, POSIX Locales or FDCC-sets and other formal descriptions of cultural conventions (type 1, 2, and 5): . . .
For POSIX Charmaps, Repertoiremaps, or TR 14652 Charmap and other formal descriptions of character sets (type 3, 4 and 6):. . .
Revise the text as follows:
For Narrative Cultural Specifications, POSIX Locales or Machine parsable cultural specifications (type 1, 2, and 5): . . .
For POSIX Charmaps, Repertoiremaps, or Machine-parsable coded character set specifications (type 3, 4 and 6):. . .
Rationale: The descriptive names of Tues 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.
Annex C External References to Cultural Specifications
C.3 Object Descriptors
CD2 TECHNICAL OBJECTION #69
Current text:
The object descriptors for the abstract syntax
object identifiers defined in 2 above shall be . . ., as assigned per clause 4
responsibility g):
Change the reference to:
...as assigned in clause 7.4, responsibility f):
Rationale: The reference is incorrect.
C.4 Transfer Syntax
CD2 TECHNICAL OBJECTION #70
Current text:
The transfer syntax as specified in ISO 8824 defines the encoding in which the contents of a registry entry might be transferred over a network. For this purpose the transfer syntaxes as defined in ISO/IEC 2022 shall be used.
Change the text as follows:
When transferring the contents of a registry entry over a network, data shall be encoded in the UTF-8 form of ISO/IEC 10646.
Rationale: Given the increasing use of ISO/IEC 10646 as a universal encoding on the network, it should be designated as the encoding to be used when transferring the contents of an entry over the network. ISO/IEC 10646-aware software is much more prevalent than ISO 8824 and ISO/IEC 2022.
Annex D Sample Narrative Cultural Specification for Danish and Irish
See Appendix 4 for comments on individual clauses in these examples.
General comments on Annex D
CD2 TECHNICAL #71
1. Confusing title
The title of this annex fails to indicate whether these
"samples" of narrative cultural specifications come from the
International Register or are extracts from applications for registration
submitted by Sponsoring Authorities. This is an important distinction.
The US recommends that the title of this annex
indicate the nature of the content of this annex.
Rationale:
Clarifies the content of the annex.
If the examples are extracts from initial applications, alerts the
user to the fact that the information in the examples will be subject to
further review (as described in clause 7.4) and should not be used in for
implementations.
2. Defective or outdated information
CD2 TECHNICAL #72
A number of items in these examples are defective or out-of-date.
The US is concerned that the publication of defective or outdated information
in the examples will reflect badly upon JTC 1 and SC 22. We are also concerned
that implementers might use the information in these examples for software
intended for use in Danish or Irish cultural locales (see preceding related
comment).
3. Concerns about status of examples
CD2 TECHNICAL #73
For the proper guidance of users of this standard, examples in
this annex should be actual examples of narrative cultural specifications as
submitted by a Sponsoring Authority after review and approval according to that
Sponsoring Authority's procedures. It is not clear that either example meets
this qualification.
Clause D.1 is entitled "Danish language
locale for Denmark, Narrative Cultural Specification".
There is a published "Danish language locale for Denmark,
Narrative Cultural Specification" (<http://anubis.dkuug.dk/cultreg/registrations/number/2>), but it
predates ISO/IEC 15897:1999, the first edition of this standard.
Clause D.1 must therefore show the narrative cultural specification from a new application (under ISO/IEC 15897) for "Danish language locale for Denmark".
Different versions of this narrative cultural specification appear in CD1 and CD2. The CD2 version differs from the CD1 version in a number of items; for example, discussion of the Greenlandic letter "KRA" has been moved from CD1 clause 12 to CD2 clause 1. The source statements are:
In CD2 - Source: Dansk Standard, date:
2002-10-08, version: 2.5
In CD1 - Source: Dansk Standard, date: 1994-07-28, version: 2.4
It is not clear which version represents the actual narrative
cultural specification submitted by Dansk Standard. (But note that the date of
the CD1 version is earlier than the publication date of the first edition of
this standard.)
CD2 TECHNICAL #74
Clause D.2 is entitled "Irish language locale for Ireland,
Narrative Cultural Specification". It is undated. Its version number is
given as "0.6 (Unofficial draft)".
The US recommends that clause D.2 be deleted until the following two conditions are met:
1)
the content of the narrative cultural specification has been finalized, that
is, it is no longer "draft"
2) the narrative cultural
specification has been officially approved as correct for Ireland by the
National Standards Authority of Ireland according to its formal procedures.
Annexes E and F
· Annex E, "reorder-after" construct in POSIX LC_COLLATE
· Annex F Information on "reorder-after" construct in LC_COLLATE)
CD2 TECHNICAL #75
Remove both Annex E and Annex F.
The US objected to these Annexes in CD1 Objections #39 and #41.
# 39: The reorder-after and reorder-end keywords are described in ISO/IEC 14651, and should not be repeated here. This annex should be removed, or rewritten simply to point to ISO/IEC 14651.
# 41: As with Annex E, the reorder-after keyword is described in ISO/IEC 14651, so information about it is not necessary in this document. This annex should be removed.
The Editor rejected both comments, stating as
his reason:
These specs are also applicable to POSIX locales
while 14651 specs are not.
The U.S. continues to object strongly to including these Annexes.
The syntax described already exists in ISO/IEC 14651, and should not be repeated
here.
If this syntax is designed to be applicable to POSIX locales, then the syntax should be in POSIX itself. It is incorrect for this standard to add normative capabilities to POSIX without the knowledge or consent of those working on ISO/IEC 9945.
There also are numerous errors in Annex E, but we are not listing them here, since we believe the entire annex must be removed. Some of the problems with the content of Annex E were described in CD1 Objection #40 (see the next comment).
Clause E.3 Example of "reorder-after"
CD2 TECHNICAL #76
This extract from N 957 gives the disposition on US Objection #40:
OBJECTION #40
Section: E.3 (Example of "reorder-after")
Current text:
". . .
<O/ <O/>;<NONE>;<CAPITAL>
<o/ <O/>;<NONE>;<SMALL>
<AA <AA>;<NONE>;<CAPITAL>
<aa <AA>;<NONE>;<SMALL>
reorder-end
. . .
2. The second "reorder-after" statement. . .initiates a
second list, rearranging the order and weights for the <AE>, <ae>,
<A:>, <a:>, <O/>, and <o/collating elements after the
<z8collating symbol in the copied specification.
. . .
4. Thus for the original sequence
...
this example reordering gives
... Uu Vv Ww Xx ( Yy Üü ) Zz ( Ææ Ää ) Øø Åå
5. . . .
the example reordering in E.3.1 gives
... ( Uu Ùù Úú ) Vv Ww Xx ( Yy __ Üü ) ( Zz Zz )
( Ææ ?Æ?æ ¯Æ¯æ Ää ) ( Øø ?Ø?ø Öö ) ( Åå ( AA Aa aA aa ) ?Å?å
)"
Problem and Action:
So much text is quoted because it is completely inconsistent. The
example syntax shows <AAand <aa>, but not Å and å (<A-ringand
<a-ring>). The explanation in item #2 includes neither the
<AA>/<aapair, nor <A-ring/<a-ring>. The reordering in item #4
shows <A-ring/<a-ring>, but not <AA>/<aa>. The reordering
in item #5 shows <AA>/<aaand <A-ring/<a-ring>.
Much of this text is wrong, but it's not clear what the author intended, so no alternative text is suggested here. Fix the text to be consistent and correct.
40. Not accepted. Text
will not been changed (for now).
This is unacceptable. US Objection #40 pointed out a serious
technical problem in the content of Annex E. The editor submitted CD2 15897 for
ballot with no changes to the defective text, but implied (via the
parenthetical "for now") that corrections might be made in the
future. Any necessary changes should have been made before CD2 15897 was issued
so that all P-members could review them as part of this ballot.
Annex H Differences from ISO/IEC 15897:1999 and CEN ENV 12005:1996
H.2 Changes from CEN ENV
12005:1996
CD2 TECHNICAL #77
Problem and Action:
The detailed changes listed for this standard as compared to CEN
ENV 12005:1996 all include references to clause numbers from the previous
draft, not this draft. For example, there is the sentence "In clause 4 the
contact information for the Registration Authority has been updated", but
in this CD2, clause 4 contains Terms and Definitions, and contact info is in
clause 7.3. This and all other incorrect references in this section must be
updated.
Bibliography
CD2 TECHNICAL #78
Current text:
2. ISO/IEC TR 14652:2001 Information technology - Specification method for cultural conventions.
Problem and Action:
This TR was not published in 2001; it has not yet been published.
ISO/IEC Directives, Part 2: Rules for the
structure and drafting of International Standards specify:
For dated references, each shall be given with
its year of publication, or, in the case of enquiry or final drafts, with a
dash together with a footnote "To be published.", and full title.
The correct publication year needs to be inserted when if it is available.
End of Specific Technical Comments
SPECIFIC EDITORIAL COMMENTS
Foreword
CD2 EDITORIAL #79
1) Change "ISO/IEC 9945-2" to "ISO/IEC 9945-1".
Rationale: The reference to ISO/IEC 9945-2 refers to an obsolete edition.
2) Change "shell and utilities" to "Base Definitions".
Rationale: In the 2002 version of ISO/IEC 9945, POSIX locales and charmaps are covered in Part 1: Base Definitions.
Introduction
CD2 EDITORIAL #80
Second paragraph, second sentence:
Change "network" to "Internet"
Rationale: "network" is a generic term
and could refer to any network. The correct term is "Internet".
JTC 1 practice appears to be to capitalize "Internet"
(as in Annex HF Glossary of Terms in Procedures for the technical work of ISO/IEC JTC 1).
CD2 EDITORIAL #81
Second paragraph, second sentence
Change "eg" to "for example,"
Rationale: Better style for an introduction.
Erroneous forms of the abbreviation "e.g." occur
throughout the text. They should all be corrected or changed to "for
example". (Both alternatives are used in ISO and JTC 1 documentation.)
4 Terms and definitions
CD2 EDITORIAL #82
Arrangement
In N 945R, the terms were arranged in alphabetical order.
Alphabetical order was not used for the Terms and definitions in CD2. The
Editor explained (in e-mail) that this was not done because translations must
be identical. When alphabetical order is used, there could be problems with a
translation. If the order of the source was retained, some terms might be out
of alphabetical order in the translation. On the other hand, if the translated
terms were ordered according to the alphabetical order of the language of
translation, the order of terms might be different in the source and the
translation.
It is difficult to see any order in the current
text, except that locale is superior to all other terms.
The specific requirement in the ISO/IEC
Directives, Part 2 is:
4.5 Equivalence of official language versions
The texts in the different official language
versions shall be technically equivalent and structurally identical. The use of
bilingualism from the initial stage of drafting is of great assistance in the
preparation of clear and unambiguous texts.
There is no stated requirement for the order of the Terms and definitions clause in a document. The order of an independent terminology standard "should be preferably classified." (clause 6.2.1). However, this clause continues:
Lists of equivalent terms in different languages may be presented either in systematic order as indicated above (in which case alphabetical indexes shall be given for each of the languages), or in alphabetical order of the terms in the first of the languages used (in which case alphabetical indexes shall be given for each of the other languages).
Note that in Annex E: Registration Definitions and Guidelines for Procedure Standards in Procedures for the technical work of ISO/IEC JTC 1, the elements in clause E.1 Definitions are ordered alphabetically.
This revised standard is being developed in English. In a translation, the number assigned to each term must be retained to meet the "structurally identical" requirement of clause 4.5 of the ISO/IEC Directives. Variations from the alphabetic order of the language of translation should be explained in a Note, for example:
NOTE: The order of the terms corresponds to their order in the original English language version of this standard.
Draft note for the French translation:
NOTE: L'ordre des termes correspond à leur ordre dans la version originale d'anglais de cette norme.
Draft note for the Russian translation:
ПРИМЕЧАНИЕ: Порядок терминов соответствует их порядку в оригинальной версии этого стандарта на Английском языке.
4.7 narrative cultural
specification
CD2 EDITORIAL #83
The definition for "narrative cultural specification"
was modified in response to CD1 Objection #9. The definition now reads:
A narrative description of culturally dependent information pertaining to software use on computers. Such information may be useful when designing computer systems and software. See clause 9.3.2 and 9.4.
Delete the phrase "pertaining to software
use on computers".
Rationale:
(a) It could be misunderstood as limiting the information only to information about ("pertaining to") the use of software on computers.
(b) It essentially repeats what the second sentence says better.
5.4.1 Structure of the identifier
CD2 EDITORIAL #84
Change the title of this clause to:
Structure of the identifiers
Note that "identifiers" should not be capitalized.
Rationale: There are two types of identifiers for
registrations.
5.4.2 Reference to an approved registration
CD2 EDITORIAL #85
The final sentence is:
Examples are listed in clause 9.3.8.
These are examples of token identifiers. At least one example of a
registration number must be given as well (either as an example here, or by
means of a reference to the place where the example appears.)
5.5 No modification nor deletion of registrations
CD2 EDITORIAL #86
Current text:
The contents of an individual registration shall
never be changed or deleted once it has been registered (except for name
additions)...
Change "it has been registered" to
"the application for registration has been approved".
Rationale:
Incorrect grammar (plural/singular mismatch)
The point at which further changes are prohibited is when the
application is approved. The rewording makes this clear.
7.3 Identity
CD2 EDITORIAL #87
Change the URL for Maintenance
agencies and registration authorities from
http://www.iso.ch/mara
to
http://www.iso.org/mara
Change the URL for Autorités
de mise à jour et organismes d'enregistrement, from
http://www.iso.ch/mara-fr
to
http://www.iso.org/mara-fr
Rationale: Although either URL works, ISO appears
to prefer ".org" to ".ch".
7.4 Registration Procedure
Item h
CD2 EDITORIAL #88
Current text:
"to inform the appropriate Sponsoring
Authority when a application does not comply to the rules."
Problem and Action:
Grammar; "...comply with the rules;"
Item f
CD2 EDITORIAL #89
The current text is identical to the text in the CD1 except that
one change -- "proposal" to "application"- has been made:
to assign to the Cultural Specification appropriate token identifiers based on the information given by the Sponsoring Authority, and to assign to the Cultural Specification the next available number to be used as a numeric identifier when the application complies with the rules, unless the Cultural Specification is identical to one already registered, in which case the new token identifiers shall be added to the existing registration;
Split this excessively complex item into a new
paragraph with two parts worded as follows:
Following approval of an application for registration, the
Registration Authority shall:
a) to assign to the a new Cultural Specification appropriate token
identifiers based on the information given by the Sponsoring Authority, and to
assign to the Cultural Specification the next available number to be used as a
numeric identifier ;
b) If the Cultural Specification is identical to one already registered, the new token identifiers shall be added to the existing registration, and the addition shall be noted in the version history of that registration;
Rationale: Reduction of
complexity.
Note that "when the proposal complies with the rules"
has been replaced by "Following approval of an application for
registration" (which occurs because "the proposal complies with the
rules").
Item i
CD2 EDITORIAL #90
In the title of this clause, change "Procedure" to
"procedure".
8.1 Identity [of the Sponsoring Authority]
CD2 EDITORIAL #91
Second paragraph:
Sponsoring Authorities may submit applications for registration of
the types Charmaps and Repertoiremaps to support their other Cultural
Specifications.
Move this paragraph to Clause 8.2 Responsibilities, and insert it immediately after item
(d).
Rationale: This paragraph describes an action that
the Sponsoring Authority may perform. It does not belong in a clause defining
the Sponsoring Authority itself.
CD2 EDITORIAL #92
Third paragraph:
Current text of this paragraph:
The RA shall reject applications for
registrations which come from sources other than Sponsoring Authorities, or
applications from Sponsoring Authorities that they do not have the authority to
register. The RA may refer the applicant (eg. a firm or an organization) to an
appropiate Sponsoring Authority, if one can be identified.
Make the changes specified below to the text of this paragraph and move the modified text to the end of the clause dealing with Registration procedures.
Rationale for moving the paragraph: This paragraph describes actions carried out by the Registration Authority. It has nothing to do with the definition of the Sponsoring Authority. It is in the wrong place.
1) Change "RA" to "Registration Authority" (two occurrences).
Rationale: For consistency with "Sponsoring Authority/Authorities" in this paragraph.
2) Change the phrase "other than Sponsoring Authorities" to "other than the Sponsoring Authorities as defined in clause 8.1."
Rationale: Current text lacks precision.
3) Delete the following text
or applications from Sponsoring Authorities that they do not have the authority to register.
Rationale:
(a)
To what does "they" refer?
(b) "they" must mean
"Sponsoring Authorities" (if "they" is interpreted as
"the Registration Authority", the text makes no sense). But
registration is done by the Registration Authority, not by Sponsoring
Authorities.
(c) A submitter of an application that does not fall into one of the categories defined in clause 8.1 is NOT a "Sponsoring Authority," merely a sponsor or a submitter.
4)
Change "eg" to "for example,"
5) Change the first comma after the
first occurrence of "Sponsoring Authorities" to a full stop (because
the remainder of the sentence has been deleted).
8.2 Responsibilities
CD2 EDITORIAL #93
Change "eg." to "for example,"
CD2 EDITORIAL #94
Item b
Change "an application" to "applications".
Rationale: For consistency with other items, where
the plural form "applications" is used.
CD2 EDITORIAL #95
Item e
Replace item e
to forward to the Registration Authority those
applications that have their support;
with the following text:
to submit applications for the registration of Cultural Specifications to the Registration Authority;
Rationale:
(a) "that have their support" is redundant. A Sponsoring Authority would not submit an application that did not have its approval.
(b) "their" à "its" ("a Sponsoring Authority" is singular)
CD2 EDITORIAL #96
Item f
Change this text:
their respective countries or organizations.
to
its respective country, region, or organizations.
Rationale: Grammar -- to agree with the implied
"Sponsoring Authority" which is singular.
Note: It is OK to drop "countries" from item f since
Sponsoring Authorities for this standard will not have jurisdiction for
multiple countries. (CEN has jurisdiction for Europe as a whole.)
# The Joint Advisory Committee for ISO/IEC 15897
CD2 EDITORIAL #97
Carry out the textual changes specified for clause 11 and then
relocate the whole clause (including its heading) immediately after clause 8 Sponsoring Authority.
Rationale: The definition of the Joint Advisory Committee must be grouped with the definitions of all other functional agencies applicable to this standard.
Currently, in CD2 15897, the abbreviation "RA-JAC" is used in clause 10, but (a) the abbreviation is not explained, and (b) the Joint Advisory Committee is not defined until the following clause (11). This is a serious editorial defect that the Editor failed to correct for CD2 15897.
Clause 9.1 Types of cultural Specifications
CD2 EDITORIAL #98
Capitalize "cultural" in the title of this clause.
Explanation: Although the title of a clause is
normally all lowercase except for the first letter, "Cultural
Specification" is treated as a proper noun (with capitals) in this
standard.
Clause 9.2 Relations between registration types
Clause 9.2.1, first sentence:
CD2 EDITORIAL #99
In clause 9.2.1, in the phrase "any of the official ISO
languages: English, French, or Russian," change "ISO" to
"ISO/IEC JTC 1".
Rationale: The Procedures for the technical work of ISO/IEC JTC 1 is the applicable authority. This is the relevant text from the Procedures:
7.9.1 The languages of JTC 1 are English, French and Russian. In general, the work of JTC 1 and its subsidiary bodies may be in any one or more of the above-mentioned languages. However, meetings are conducted in any one of these. The Chairman or Convener is entitled to authorize participants to speak in a language other than that in which the meeting is conducted. The NB for the Russian Federation provides all interpretation and translation into or from the Russian language into or from another official language.
Clause 9.3 Rules for Cultural Specifications
Clause 9.3.5
CD2 EDITORIAL #100
Current text:
The sources shall be delivered electronically, either via electronic mail or on a diskette, to the Registration Authority.
Reword as:
either via electronic mail or on physical storage media
Rationale: Current wording is too restrictive and
backward looking.
Clause 9.3.7
CD2 EDITORIAL #101
Change "all" to "All"
Rationale: Orthographic conventions.
Clause 9.3.8
CD2 EDITORIAL #102
Current text of the 6th paragraph (between the two
Notes) ends:
... thus giving preference specifications from
National Standardization Organizations.
Insert "to" between "preference" and
"specifications"
Rationale: Grammar.
Clause 9.4 Contents of a Narrative Cultural Specification
CD2 EDITORIAL #103
Wherever possible in the text describing the individual clauses,
change the passive "Here ... is described" construction to "This
clause describes ..." (or "This clause includes ..." when only
some of the contents of the clause are mentioned).
Clause 1: Alphanumeric
deterministic ordering
CD2 EDITORIAL #104
Current text:
Issues to cover may be: are there any letters that are sorted differently from other languages, are capital letters sorted before small letters, are there a specific ordering of accents, in which order should different scripts be, do some characters sort equally at first and then when the whole string is otherwise consider red equal, should they then be sorted differently at other levels?
Rewrite as:
Issues to cover may include whether there are letters that sort differently from common use in other languages, whether capital letters sort before small letters, or whether there is a specific ordering of diacritics. Further, this section may describe the ordering of scripts, and sorting levels -- that is, if there are cases when characters sort equally at first, but then may sort differently at other levels.
Rationale: Grammar.
CD 2 EDITORIAL #105
The title of this clause is inappropriate because its content may
cover scripts that are not alphabets. New name should be:
Ordering of textual data
Clauses 7 through 32
See Appendix Four for US technical and editorial comments on the
optional (non-POSIX) clauses.
10 Appeal procedures
CD2 EDITORIAL #106
Delete the first line of text:
Appeal against the decision of the Registration Authority can be
made as follows:
Rationale: Redundant. The title of the clause says
the same thing more succinctly.
Clause 11.2
First paragraph
CD2 EDITORIAL #107
Spelling of "subcommittee' still has to be corrected by
inserting "t".
Annex A Application form for a Cultural Specification
Introductory paragraph
CD2 EDITORIAL #108
Current text:
Please specify all data relevant for the
Cultural Specification type, indicating non-available data by "not
available"...
Reword as:
Please specify all data relevant for the Cultural Specification
type, or enter "not applicable"...
Rationale: Clarity.
Annex D Sample Narrative Cultural Specification for Danish and Irish
CD2 EDITORIAL #109
Change title of Annex D to:
Examples of Narrative
Cultural Specifications
Rationale:
(a) These are "examples", not "samples". (For examples of use, see Annex B and Annex G in ISO/IEC Directives, Part 3 Rules for the structure and drafting of International Standards)
(b) The examples are intended to show the content of narrative cultural specifications, without emphasis on language.
Annex H Differences from ISO/IEC 15897:1999 and CEN ENV 12005:1996
H.1 Changes from ISO/IEC
15897:1999
CD2 EDITORIAL #110
Current text:
3. The text was revised to align with wordings
of the new ISO/IEC 2375 International Standard, which the original wordings in
the CEN ENV 12005 was build from.
Reword as:
3. The text was revised to align with ISO/IEC 2375.
Rationale:
(a)
Grammar ("wording" is singular; "was built" not "was
build")
(b) Removal of text that applies to the
1999 version of this standard.
CD2 EDITORIAL #111
Current text:
7. Some parts of the text was moved around, eg
annex G which is now clause 9.4.
Reword as:
7. Some parts of the text were moved around. For example, the
former Annex G is now clause 9.4.
Rationale: Grammar.
End of Specific Editorial Comments
APPENDIX 1
US comments on specific aspects of the text of clause 7.4
The US recommends (see Technical Comments) that clause 7.4 be replaced by two more detailed clauses. The comments in this appendix identify problems with the text of clause 7.4 as it exists.
Item c
CD2 TECHNICAL #112
Current text:
to circulate applications to ISO/IEC JTC1/SC22
members, liaisons and the Registration Authority's Joint Advisory Group,...
Insert a reference identifying the clause where the Registration Authority's Joint Advisory Group is described in detail immediately after "Group".
Rationale: The RA-JAC has not yet been defined.
CD2 TECHNICAL #113
The text of item c, clause 4 Registration
Authority of the CD1 reads:
in the case of a POSIX Locale, to ascertain that the POSIX Locale and the corresponding Narrative Cultural Specification are not in contradiction
In CD1 Objection #12, the US asked:
What if the two do contradict each other? Suppose there is a "foo" POSIX locale definition, and a "foo" narrative cultural spec. Suppose the cultural spec includes <a-acutein the character set list, but the locale does not include it in the <alphaclass. Now what? Which is considered wrong? Is one rejected, or asked to be revised? What if the locale was registered a few years ago, and changing attitudes now make the fact that <a-acuteis not included obsolete? To give a concrete example, locales from the early 1990s often include a limited repertoire of characters -- Western European ones may only include a subset of ISO 8859-1 characters. Locales (or cultural specifications) written now often take a broader definition of what should be included. Under this clause, is one of these wrong? What must be done? Should the older one be marked obsolete? What about users who depend on it?
The existing text is incomplete and vague about the Registration Authority should do if a contradiction exists. More information must be added - once decisions about what happens have been made.
In the DoC, the Editor responded:
12. Noted. There will always be errors. The RA should probably send an application back if it sees errors, and the SA would then have a chance to correct and then resubmit. The RA should then register, and probably come forward with comments. The RAC could also make comments. N 945R is addressing this, and text will be added to clarify it.
In the CD2, the responsibility for resolving inconsistencies between a POSIX Locale and the corresponding Narrative Cultural Specification appears to have now been assigned entirely to the Sponsoring Authority (clause 8.2 Responsibilities [of a Sponsoring Authority], item c).
in the case of a POSIX Locale, to ascertain that the POSIX Locale and the corresponding Narrative Cultural Specification are not in contradiction;
Item d
CD2 TECHNICAL #114
Current text:
to forward the comments received to the Sponsoring Authority for possible integration in the final documents;
Problem and Action:
From this text, it sounds as if the RA is merely a clearinghouse
for comments; that it makes no judgments on the contents of proposals or on
comments that others make. Is that the case? It seems more appropriate for the
RA to be the body that debates the contents and decides whether they are
acceptable. Otherwise, it appears that the SA has all the power to decide what
a proposal will contain, as well as power to dispose of any comments received.
This problem is addressed in the first of the two clauses that the US proposes as replacements for clause 7.4. In particular, following technical review by the RA-JAC,
x.7 The Registration Authority shall inform the Sponsoring Authority of any changes needed to satisfy the concerns of the RA-JAC.
and, following review by the P-members of SC22,
x.9 The Registration Authority shall consider all comments received. The Registration Authority shall request the RA-JAC to provide expert advice on the technical comments. The Registration Authority may incorporate comments resulting from the review specified in clause <x.8> into the final registration.
Item e
CD2 TECHNICAL #115
Current text:
in the case of comments, to optionally receive from the Sponsoring Authority revised applications addressing the comments received;
Substitute this text for the current text:
to receive revised applications from the Sponsoring Authority that address comments made about the application by reviewers, and to decide whether the revisions are acceptable;
Rationale:
1)
There is no way to "optionally receive" something. Shouldn't this say
"...optionally accept"?
2) The "optionally" is
perhaps intended to convey the fact that not every application will need to be
revised in response to comments.
3) "in the case of comments" is redundant.
End of Appendix 1
APPENDIX 2
Rearrangement of Clause 9 Rules for Applications
To facilitate the use of ISO/IEC 15897, the US proposes that clause 9 be reorganized into six separate clauses dealing with these topics:
1.
Types and relationships of cultural specifications;
2. Contents of a narrative cultural
specification;
3. Use of character names;
4. Requirements for applications;
5. Format of registration documents;
6. Specification of the token
identifier;
In the rearrangement, an ordinal number enclosed in square brackets (for example, "[1st]") represents the number of a main clause. Subclauses are numbered in the usual way.
The text is almost entirely taken from clause 9 of N 987. Text from N 987 has been copied "as is," which means that typographical or grammatical errors have not been corrected. Clause numbering from N 987 is included as an aid to reviewers.
The very few pieces of text that were inserted or deleted for stylistic
reasons are shown by
underline or strikethrough respectively. US recommendations for changes to the
text itself have NOT been applied here, so that reviewers can focus entirely on
how this clause ought to be restructured.
[1st]. TYPES AND RELATIONSHIPS
OF CULTURAL SPECIFICATIONS
[1st].1 Types of cultural specifications = 9.1
Types of cultural Specifications
A number of types of Cultural Specifications can be registered
according to this International Standard:
1. Narrative Cultural Specification
2. POSIX Locale
3. POSIX Charmap
4. POSIX Repertoiremap
5. Machine-parsable cultural specification
6. Machine-parsable coded character set specification
Type 1 are for Narrative Cultural
Specifications, further specified in clause 9.3.2.
Types 2 and 3 are for POSIX specification of cultural conventions
defined in ISO/IEC 9945-2.
Type 4 is for Repertoiremaps defined in this International
Standard (clause 9.3.9) and in ISO/IEC TR 14652.
Types 5 and 6 are for specification of cultural conventions in a
machine-parsable format, such as specified in ISO/IEC TR 14652, XML or SGML
table formats. Any format is allowed as long as it is machine parsable and
adheres to the following rules: It is a TR 14652 FDCC-set, a TR 14652 charmap,
or the first line of the file identifies the file format.
[1st].2 Relations between
registration types = 9.2 Relations between registration types
The relation between the types is the following:
Registration types are related as follows:
[1st].2.1 Narrative Cultural Specification
9.2.1. The Narrative Cultural Specification specify cultural
conventions in narrative form in any of the official ISO languages English,
French and/or Russian, and it may give equivalent specifications in other
languages. It may thus address issues which have not yet been codified by
formal methods for specifications of cultural conventions. If parts of a
Narrative Cultural Specification has been specified also in POSIX Locale or
Charmap format, this Locale or Charmap should be referenced in the
specification.
[1st].2.2 POSIX Locale
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.
9.3.3 (part) The POSIX Locale shall define all standard categories (for example by copying categories of a standard POSIX Locale; examples are given in annex F).
9.4 (part) If a POSIX locale is submitted, it is desirable that it be accompanied by a related narrative cultural specification.
[1st].2.3 POSIX Charmap
9.2.3. The POSIX Charmap shall specify aspects of a Narrative
Cultural Specification or a POSIX Locale that relate to coded character sets. A
POSIX Charmap shall refer to the Repertoiremap being used, but need not refer
to the POSIX Locales nor the Narrative Cultural Specifications using it.
[1st].2.4 Repertoiremap
9.2.4. The Repertoiremap is used as a tool to enable a POSIX
Locale or a Narrative Cultural Specification to be independent of coded
character sets, and to remove the requirement for POSIX Charmaps when
registering a POSIX locale. It need not refer to other Cultural Specifications.
[1st].2.5 Other specifications
9.2.5. 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.
9.3.3 (part)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).
9.2.6. 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.
NOTE: It is the intention to allow more formal specification methods in future revisions of this International Standard when they become standardized methods; for the time being these specifications can be registered as type 1, 5 or 6.
[2nd]. CONTENTS OF A NARRATIVE
CULTURAL SPECIFICATION
= 9.4 Contents of a Narrative Cultural
Specification
The contents of the Narrative Cultural Specification is described
in some detail in the following. it builds on information from the POSIX Shell
and Utilities standard (ISO/IEC 9945-2) and the Nordic Cultural Requirements on
Information Technology Summary Report.
Clause 7 to 32 are to provide information, which is not presently expressible in POSIX notation. Examples of Narrative Cultural Specifications are given in annex D.
[2nd].1 Mandatory Clauses
9.3.2 The format of a Narrative Cultural Specification shall
contain the clauses (numbered 1-6) specified below. 9.4 These clauses are POSIX
categories. The Narrative Cultural Specification should be accompanied by a
corresponding POSIX Locale specification. 9.3.2 The information given in these
clauses of the Narrative Cultural Specification may also be described in an
FDCC-set, or other machine parsable cultural specification:
Clause 1:
Alphanumeric deterministic ordering
Here the specification of a national standard for ordering should
be listed. If there are more standards, or options for a standard, there should
be one POSIX specification for each of the standards or options. A European
Multilingual Sorting standard, or other international standards, already in
this registry, could be referenced and possible deviations, if any, could be
described. Issues to cover may be: are there any letters that are sorted
differently from other languages, are capital letters sorted before small
letters, are there a specific ordering of accents, in which order should
different scripts be, do some characters sort equally at first and then when
the whole string is otherwise considerered equal, should they then be sorted
differently at other levels? Does the language require reordering of some
characters before collation weighting (e.g. Thai)? Does the language sort on a
syllabic basis, rather than merely letter-by-letter (e.g. Burmese)? Does the
language make use of ideographs, and if so, how are they handled with respect
to other characters? If aspects of the ordering for the language extend beyond
what a POSIX specification can handle, then details can be described in Clause
10.
Clause 2:
Classification of characters
The POSIX standard allows descriptions of what is alphabetic
characters, capital and small letters, digits, hexadecimal digits, punctuation
characters, spaces, graphical characters and control characters.
Clause 3:
Numeric formatting
Here it is described how numbers are keyed in and formatted,
including the format of the decimal point and the thousands separator.
Clause 4:
Monetary formatting
Here formatting rules for monetary amounts, as well as local and
international currency symbols according to ISO 4217, are described, as well as
the relation between the amount, a sign and the currency symbol.
Clause 5:
Date and time conventions
Various names for days and months are given, together with formats
for writing date and time. Things to consider are: do day and month names start
with a capital letter or a small letter? Are there well recognized
abbreviations for the day and month names? Is ISO 8601 formatting widespread?
As the date formats are for use in POSIX, for example when listing files,
consideration should be given to possible POSIX conventions in the culture.
Clause 6:
Affirmative and negative answers
Here the short notation for "yes" and "no"
answers in the language can be specified. If the culture has strong relations
to several languages, for example in a multilingual country, it should be
permitted to answer in any of the languages. As English is widely used in many
cultures, allowing responses in the English language should be considered.
[2nd].2 Optional Clauses
9.3.2 (remainder) The Narrative Cultural Specification may also
include other culturally dependent information, specified in clauses 7-32. 9.4
These clauses are not directly related to POSIX Locales:
NOTE: Further information
about the categories, along with specific examples illustrating their use may
be found in clause 9.4
and in the Nordic Cultural Requirements on Information Technology
(Summary Report).
Clause 7:
National or cultural Information Technology terminology
Here terminology for a language or culture can be listed, for
example a translation of ISO terminology for Information Technologies.
Clause 8:
National or cultural profiles of standards
Here profiles of standards can be listed, for example, OSI national
profiles, or profiles of the POSIX standards. See the POSIX ISO/IEC 9945-2
standard for an example.
Clause 9:
Character set considerations
Here it can be described how characters are used in the culture,
for example:
- which characters are necessary to write a particular language,
- which characters are used to give further precision in the
language,
- which characters are usually used in newspapers and books for
writing of names and places,
- which characters are used for historic writing of the language,
- and which characters are used for other purposes.
This clause may also be used to specify which coded character sets
are common in the culture and what coded character sets are recommended. Also
further descriptions of coded character sets may be described; it is also
possible to document these in the form of a POSIX Charmap registration.
9.3.2 (part) In clause 9 it is possible to give
further information on characters classified in clause 2 (mandatory).
Clause 10: Sorting and
searching rules
This is much like clause 1, but can be used for further
descriptions, such as how to split a record into sorting fields, and special
words which are ignored when comparing or searching. Also sound based matching
rules may be described here. What can be accomplished with POSIX should be
described in clause 1.
Clause 11:
Transformation of characters
Here transliterations and transformations of characters can be
described, for example transliteration rules between Latin, Greek and Cyrillic,
or fallback notation for some frequent letters. Also this is the place to write
about standards in the culture for character conversion.
Clause 12:
Character properties
Here additional considerations further than those given in clause
2 can be given, for example how small letters without a direct capital
counterpart may be capitalized, or special capitalization rules.
9.3.2 (part) Clause 12 is for description of cultural aspects in excess of what can be described in the corresponding POSIX clause 2.
Clause 13:
Use of special characters
Here use of special characters, such as quotation marks,
abbreviation marks, and punctuation marks can be described. Also interesting
here may be what to avoid, for example number signs, pilcrow sign and division
signs are not used in documents in several cultures. Spacing rules and the
relation between different punctuation signs is also relevant here.
Clause 14:
Character rendition
Special considerations about rendition such as what alternatives
may be considered adequate, and acceptable glyphs, may be described in this
clause.
Clause 15:
Character inputting
A keyboard seldom has separate keys for all the characters needed.
This clause is intended for description of keyboard inputting rules and other
input methods.
Clause 16:
Personal names rules
Personal naming differs from culture to culture, for example what
is considered the family name, how titles are used, are family names spelt
thruout in capital letters, and whether given names or initial are used. Also
the rules for children inheriting their fathers' and mothers' family name, and
what happens for married couples may bedescribed here.
Clause 17:
Inflection
Languages vary much with respect to inflection, different forms of
words depending of the context. here the rules can be described or referenced.
Some common translation APIs today take some aspects of this into account, eg.
the UNIX gettext() functions deal with singular/plural forms of nouns.
Clause 18:
Hyphenation
Hyphenation rules can be described here, and also references to
the specifications for a language may be done here.
Clause 19: Spelling
This clause is for specification of spelling rules and spelling
lists, or reference to orthographic documentation.
Clause 20: Numbering,
ordinals and measuring systems
Here measurement systems can be described (normally this is the
ISO SI system). Use of decimal points and thousands separator should be
described in clause 3.
9.3.2 (part) Clause 20 is for description of cultural aspects in excess of what can be described in the corresponding POSIX clause 3.
Clause 21:
Monetary amounts
Here further considerations to clause 4 can be described, such as
old currencies.
9.3.2 (part) Clause 21 is for description of cultural aspects in
excess of what can be described in the corresponding POSIX clause 4.
Clause 22:
Date and time
This is for considerations in excess of clause 5, such as
non-POSIX date conventions, time zone names and daylight savings rules, and
other written expressions like "half seven" - what is then really
meant - 06:30 as in Germany or Denmark, or 07:30 as in Britain?
9.3.2 (part) Clause 22 is for description of cultural aspects in excess of what can be described in the corresponding POSIX clause 5.
Clause 23:
Coding of national entities
Here coding for different entities can be described, such as
postal codes, administrative codes for local government, police districts,
abbreviations for cities or provinces, and time zone names relating to
different parts of the culture.
Also specifications should be given for identification of the whole culture, for example ISO country codes for a nation.
Clause 24:
Telephone numbers
The formatting of telephone numbers, nationally and internationally.
Clause 25: Mail addresses
The formatting of postal addresses, where to put the title of the
addressee, the street number and the postal code, what are the names of the
storeys, and other conventions used.
Clause 26:
Identification of persons and organizations
A culture may have numbering schemes for persons and
organizations, for example social security numbers, and general tax numbers for
companies, together with registries for different organisation forms such as
limited companies and associations. This clause may be used to describe such
numbering systems.
Clause 27:
Electronic mail addresses
Cultural conventions for Internet and X.400 electronic addresses
etc. may be described here.
Clause 28: Payment
account numbers
Cultural conventions for bank account numbers can be described
here.
Clause 29: Keyboard
layout
Here the conventions for keyboard layout may be described.
Clause 30: Man-machine
dialogue
Considerations for how to localize products may be described here.
9.3.2 (part) Clause 30 is for description of cultural aspects in
excess of what can be described in the corresponding POSIX clause 6.
Clause 31:
Paper formats
Here it can be described what the conventions are for paper size
(normally ISO standards) and the use of window envelopes, etc. Also how punched
holes are placed in paper may be relevant here.
Clause 32:
Typographical conventions
This clause may be used for how layout is done, for example how to
layout a business letter, or a fax. Use of special characters, for example quotation
marks, should be described in clause 13.
[2nd].3 Limitations on
Character Content
9.3.7 (part) The information in items 8 to 14 is used in the token
identifier for the Cultural Specifications.
Items 8 to 13 may contain digits 0123456789 and the characters
uppercase and lowercase forms of
ABCDEFGHIJKLMNOPQRSTUVWXYZ
Item 10 may also contain the special characters:
/()*-.:_
Note: all of these characters are included in ISO/IEC 10646-1
U0020..U007E.
Case of letters is not significant in token identifiers.
[3rd]. USE OF CHARACTER NAMES
9.3.9 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 name. It is recommended to use, whenever possible, character
names specified in ISO/IEC 9945-2:1993 Annex G. The character name and the
ISO/IEC 10646 canonical encoding are each surrounded by angle brackets
<>, and the fields shall be separated by one or more spaces or tabs on a
line. If a right angle bracket or an escape character is used within a name, it
shall be preceded by the escape character. The escape character can be
redefined from the default reverse solidus (\) with the first line of the
Repertoiremap containing the string "escape_char" followed by one or
more spaces or tabs and then the escape character.
[4th]. REQUIREMENTS FOR
APPLICATIONS
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.
9.3.7 (part) Annex A specifies a form to be filled out for each Cultural Specification; Annex B gives an example of a completed form.
9.3.7 (part) If any of the above information
specified below is non-existent, it must be stated in each case; the
corresponding string is then the empty string. The default case in 11 and 12 is
also represented by an empty string. If required information is not present in
any of the ISO 639 parts or ISO 3166, the relevant Maintenance Authority shall
be approached by the Sponsoring Authority to get the needed item registered.
[4th].1 Required for All
Applications
9.3.7 The written Cultural Specification application shall contain
information on the following items:
1. Cultural Specification type number (as in 9.1 above)
2. Organization name of Sponsoring Authority
3. Organization postal address
4. Name of contact person
5. Electronic mail address of the organization, or contact person
6. Telephone number for the organization, in international format.
7. Fax number for the organization, in international format.
All applications shall contain information on these items:
11. If not for general use, an indication of the intended user
audience. The Registration Authority decides on a corresponding identifier
element, to be used in the token identifier for the specification.
12. If for use of a special application, a description of the application. The Registration Authority decides on a corresponding identifier element, to be used in the token identifier for the specification.
13. Short name for Sponsoring Authority, for possible use in the token identifier. Blank if this is from a National Standardization Organization.
14. Revision number consisting of digits and
zero or more full stops (".").
15. Revision date in the format according to this example:
"1995-02-05" meaning the 5th of February, 1995.
[4th].2 Required for Types 1, 2 and 5
9.3.7 (part) For Types 1, 2, and 5, Narrative Cultural
Specifications, POSIX Locales, and FDCCsets and other formal descriptions of
cultural conventions:
8. Natural language, as specified in ISO 639-1,
or ISO 639-2 terminology codes if an ISO 639-1 code does not exist.
9. Territory, as two-letter form of ISO 3166
[4th].3 Required for Types 3, 4, and 6
9.3.7 (part) For Types 3, 4, and 6, POSIX Charmaps,
Repertoiremaps, and TR 14652 Charmaps and other formal descriptions of
character sets:
10. Suggested Charmap or Repertoiremap or other name
[5th]. FORMAT OF REGISTRATION
DOCUMENTS
[5th].1 General
9.3.1 A application for registration of a Cultural Specification
shall be submitted as a Text File. A Narrative Cultural Specification may
alternatively be submitted on white paper of the approximate size 297 by 210
mm, with margins of no less than 20 mm, or one of the approved document formats
of ISO/IEC JTC 1, as noted in JTC 1 directives.
9.3.5 The sources shall be delivered electronically, either via electronic mail or on a diskette to the Registration Authority. Narrative Cultural Specifications may alternately be delivered on paper.
9.3.4 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. Comments shall be given in the English language, and equivalent comments may also be given in other languages. If characters outside ISO/IEC 646 International Reference Version are needed, character names defined in a Repertoiremap shall be used.
[5th].2 Narrative Cultural
Specification
9.3.2 (part) Each clause shall begin on a new line after at least
one blank line, and each clause shall be introduced by the string "Clause
", followed by the decimal clause number for the issue as listed above,
then a colon and a space, and then the title of the clause, using the titles
above (examples are given in annex D).
9.3.2 (part) The body of the clause shall follow on the succeeding lines. A reference to a clause within the specification shall consist of the string "=> Clause " followed by the clause number. A reference to another specification shall consist of the string "=> Spec. "followed by the registration number of the specification and, optionally, the string "Clause " and a clause number.
[5th].3POSIX Locale and Charmap
9.3.2 (part) 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.
[5th].4 Repertoiremap
9.3.2 (part) The format of the Repertoiremap shall be conformant
to clause 9.3.9.
[6th]. SPECIFICATION OF THE
TOKEN IDENTIFIER
Token Identifiers are assigned by the Registration Authority.
9.3.8 The information in item 8 to 14 is used by the Registration
Authority to construct a token identifier for the Cultural Specification
according to the following rules. The token identifier may then be used to
uniquely identify a Cultural Specification in a manner that may be more
indicative of its contents than a mere numeric identifier.
For Narrative Cultural Specifications, POSIX
Locales and FDCC-sets the token identifier will be:
8_9+11+12,13_14
And for Charmaps and Repertoiremaps the token identifier will be:
10+11+12,13_14
where 11 and 12 and preceding pluses shall be omitted when not
needed to specify position, and 13 may be omitted after request from the
Sponsoring Authority, if this is a National Standardization Organization.
The HYPHEN character "-" may be substituted for the UNDERLINE character "_", in order to align names with RFC 3066.
NOTE: A combination of a POSIX Locale or FDCC-set, and a Charmap may be designated by the Locale or FDCC-set identifier and the Charmap identifier separated by a solidus (/).
When referencing a Cultural Specification, the version number or parts thereof taken from the right may be omitted, to refer to the Cultural Specification with the highest digital version number available with the given version number prefix. If the item 13 is an empty string, referencing the token identifier without the preceding comma and items 13 and 14 shall give the Cultural Specification with the highest digital version number, thus giving preference specifications from National Standardization Organizations.
NOTE: The version number may be used by the Sponsoring Authority to mark major releases, minor revisions and error corrections. It is recommended that major releases be reflected as the first number, minor revisions in the second number, and error corrections in the third number.
EXAMPLE 1: _EU,CEN_3.5 for the CEN European
POSIX Locale
EXAMPLE 2: da_DK,_2.4 for the Danish Standards Danish POSIX Locale
EXAMPLE 3: ISO_8859-1:1987,DS_1.0 for the DS Charmap for ISO
8859-1
End of Appendix 2
APPENDIX 3
Technical and editorial comments on optional (non-POSIX) clauses
Clause 8: National or cultural
profiles of standards (Optional)
CD2 TECHNICAL #116
Current text:
"Here profiles of standards can be listed,
for example, OSI national profiles, or profiles of the POSIX standards. See the
POSIX ISO/IEC 9945-2 standard for an example."
Problem and Action:
The reference to POSIX is out-of-date and obsolete. ISO/IEC 9945-2
now contains system interface definitions, and does NOT contain an example of a
profile.
Remove the sentence "See the POSIX..."
Clause 11: Transformation of
characters (Optional, Not recommended)
CD2 TECHNICAL #117
Current text
Here transliterations and transformations of
characters can be described, for example transliteration rules between Latin,
Greek and Cyrillic, or fallback notation for some frequent letters. Also this
is the place to write about standards in the culture for character conversion.
In CD1 Objection #49, the US proposed removal of
this clause because:
This is too vague to be useful, as the Danish
example in Annex D illustrates.
The Editor responded in the DoC:
49. Not accepted. There are already many quite elaborate transliteration specs in 14652 style.
The US recommends that this clause be annotated
"Not recommended."
Rationale: The instructions on the content of this
clause are too vague to be useful (as the Danish example in Annex D illustrates).
CD2 TECHNICAL #118
If actual, usable "elaborate transliteration specs in 14652
style" exist, then at least one appropriate example should be cited (and
added to the Bibliography). This will provide that Sponsoring Authorities with
a well-formed example of what should be in this clause.
Clause 13: Use of special
characters (Optional)
CD2 TECHNICAL #119
Although the US comment CD1 OBJECTION #31 to "revise the text
to clarify the information about order" was not accepted, the text dealing
with quotes in Clause 13 has been revised and is clearer:
For quoting, the character pairs <"><">, <«><»> and <"><">are used,; the first character in each pair is used to start a quote, and the last to end the quote.
CD2 TECHNICAL #120
Clause 13 is a collection of examples of use of special characters
(or advice on use in the case of the number sign). What is needed is a
definition stating exactly what "special characters" are.
CD2 TECHNICAL #121
Delete this line:
NUMBER SIGN <#> is seldomly used, and
should be avoided.
Rationale: Dictating whether a country or region
should make use of NUMBER SIGN in its orthography is totally out of scope for
this standard.
CD2 EDITORIAL #122
The US notes that "seldomly" is grammatically incorrect.
The correct usage is "seldom".
Clause 16: Personal name rules
(Optional, Not recommended)
CD2 TECHNICAL #123
Current text:
Personal naming differs from culture to culture,
for example what is considered the family name, how titles are used, are family
names spelt thruout in capital letters, and whether given names or initial are
used. Also the rules for children inheriting their fathers' and mothers' family
name, and what happens for married couples may be described here.
Problem and Action as stated in CD1 OBJECTION
#50:
"While this may be interesting information, of what use is it
to software developers? For most countries, there are general conventions about
family names, but so many individual exceptions that the conventions cannot be
hard-coded into software. What is the justification for including this
information?"
The DoC was "Not accepted. see 33."
(CD1 Objection #33 was a comment on the Danish example in Annex D.)
DEFECTIVE DISPOSITION. While it was appropriate to refer Objection
#33 to the Danish NB for resolution, it is incumbent upon the editor to respond
to the problems identified CD1 Objection #50.
The US notes that the editor did correct "first" to "given" (as suggested in #33).
CD2 TECHNICAL #124
The US recommends that this clause be annotated "Not
recommended".
Rationale: It is questionable that the information
requested here, which may include many exceptions, can be expressed in
software.
Clause 17: Inflection
(Optional, Not recommended)
CD2 TECHNICAL #125
Current text:
"Languages vary much with respect to
inflection, different forms of words depending of the context. here the rules
can be described or referenced. Some common translation APIs today take some
aspects of this into account, eg. the UNIX gettext() functions deal with
singular/plural forms of nouns."
Remove the sentence beginning "Some common
translation APIs..."
Rationale:
First, gettext() is not a translation API; it is a messaging API.
Second, while it may have some very, very limited capabilities with respect to
singular/plural nouns in a few languages, it most definitely does NOT have the
capability of handling all the varying inflection rules that languages around
the world use. This is misleading at best and inaccurate at worst.
CD2 TECHNICAL #126
The US recommends that this clause be annotated "Not
recommended".
Rationale: It is questionable that the information
requested here, which may quite complex for some languages (as shown by the
Irish example), can be expressed in software.
Clause 20: Numbering, ordinals,
and measuring systems (Optional)
CD2 EDITORIAL #127
In the technical comment on Clause 3: Numeric formatting, it was
pointed out that information on how numbers are "keyed in" could not
be included since Clause 3 is defined as a POSIX category, and "POSIX
contains no information about how numbers are "keyed in".
In case information about keying in is needed, the US provides the following replacement text:
This clause includes the description of the measurement system or systems used. (Usually, the measurement system is the ISO SI system.). A description of how numbers are keyed in may be included here. Use of decimal points and thousands separator shall be described in clause 3.
This replacement text also fixes these defects:
(a)
corrects the erroneous plural "decimal points";
(b) changes "should" to
"shall" in the last sentence. Clause 3 is a required data element of
a registration (as specified in clause 9.3.2).
Clause 22: Date and time
(Optional, Not recommended)
CD2 TECHNICAL #128
Current text:
"This is for considerations in excess of
clause 5, such as non-POSIX date conventions, time zone names and daylight
savings rules, and other written expressions like "half seven" - what
is then really meant - 06:30 as in Germany or Denmark, or 07:30 as in
Britain?"
The U.S. still objects strongly to including time zone information in cultural narratives (as stated in CD1 Objection #51).
Remove the phrase "...time zone names and
daylight savings rules..."
Additional Rationale:
Time zones cross national borders and so are not limited to a
single culture. Also, time zone information in a locale or cultural narrative
was labeled controversial in TR 14652, and it is incorrect to elevate it to
normative status in this standard.
CD1 OBJECTION #51
Section: Annex G, clause 22 (Date and time)
Current text:
Text is now in 9.4, clause 22
"This is for considerations in excess of clause 5, such as
non-POSIX date conventions, time zone names and daylight savings rules, . .
."
Problem and Action:
Time zone names and daylight savings rules should not be in a
cultural narrative. Especially for large countries, there are too many zones
and local exceptions for this information to be useful. Time zones are
geographical and political rather than cultural.
Remove this clause.
51. Not accepted. The information can be
used to set TZ, and in the case of more than one, it can be used to select the
correct one.
CD2 TECHNICAL #129
The example is defective. "Half seven" is an English
language phrase, and means 7:30 am or pm (that is, 0730 or 1930 hours). The
German phrase "halb sieben" means only 0630. (The Danish NB is
invited to supply the corresponding Danish phrase for 0630.)
We also note that "half seven" is British usage. English-speakers in other cultures (US and Australia, for example) say "half past seven."
CD2 TECHNICAL #130
If the phrase "...time zone names and daylight savings
rules..." is not removed, then the US strongly recommends that this clause
be annotated "Controversial" (rather than simply "Not
recommended").
Rationale: To agree with WG20's
decision on time zone information in TR 14652.
If the phrase "...time zone names and daylight savings
rules..." is removed as the US has requested, then this clause should
be annotated "Not recommended".
Rationale: Because there are problems with all aspects of the description.
Clause 23: Coding of national
entities (Optional, Not recommended)
CD2 TECHNICAL #131
The US recommends that this clause be annotated "Not
recommended".
Rationale: The instructions on the content of this
clause are too vague to be useful.
Clauses 26, 27, 28 and 30
(Optional, Not recommended)
CD2 TECHNICAL #132
26. Identification of persons and organizations
27. Electronic mail addresses
28. Payment account numbers
29. Man-machine dialogue
The US recommends that these clauses be annotated "Not
recommended".
Rationale: The definitions are vague, or contain
information that is application-specific rather than culture-specific.
End of Appendix 3
APPENDIX 4
US Comments on Annex D, Sample Narrative Cultural Specification for Danish and Irish
Objections specific to the Danish or Irish
examples are listed here.
These US comments consist of new comments on the CD2, and earlier
comments (previously submitted with the US vote on CD1) that are still
applicable to the CD2. These are distinguished by the prefix "CD2" or
"CD1". Some objections are specific instances of general comments
above.
In N 957 Disposition of comments on CD of 15897 (that is, CD1), the Editor responded:
28-38. These comments will be relayed to the Danish member body for possible changes.
Comments 28-37 were not accepted for this reason.
Corrections to the Danish example should be done with input from the Danish member body. The Danish member body is kindly invited to provide suggestions for changes, if appropriate.
This consolidated list of comments is submitted to assist the Danish and Irish NBs should they wish to address the US concerns expressed in the US comment on this Annex as a whole.
CD1 OBJECTION #28
Section: Annex D, Clause 7 (National or cultural Information
Technology terminology)
Current text:
"The official Information Technology terminology is
"Edb-ordbog", DS 2049-1970, Gjellerup, København. A newer description
can be found in Lars Frank: "edb-ordbogen", Kommunetryk, København
1984."
Problem and Action:
Citing documents that were written 31 and 17 years ago as relevant
for information technology is not useful. Technology and its terminology change
so quickly that these documents must be out-of-date. Remove this clause.
Perhaps there are more recent IT vocabulary sources for Danish speakers that could be cited.
CD2 TECHNICAL #133
Section: Annex D, Clause 11
Current text:
"Transliteration of Cyrillic and Arabic is
quite different from English conventions. Examples of transliterated Cyrillic
names are Tjajkovskij, Gorbatjov, and Jeltsin; an example of a translitterated
Arabic name is Khadaffi. For a fallback notation of some letters, refer to the
following table:"
Problem and Action:
It still is not clear why the Danish Standards body
wants to state that transliteration "...is quite different from
English" without giving a full description, but that is their choice.
However, do they really want to provide a list of "fallback notation of
*some* letters" (emphasis added)? Wouldn't it be preferable to provide a
full list?
Editorial: correct spelling of second
use of "transliterated".
The US previously commented on this clause as follows:
CD1 OBJECTION #29
Section: Annex D, Clause 11 (Transformation of characters)
Current text:
"Transliteration of Cyrillic and Arabic is very different
from English conventions.
For a fallback notation of some letters, refer to the following
table:
original letter 2-char 1-char
Æ AE E
Ø OE Y
Å AA O
. . ."
Problem and Action:
According to Annex G, this clause is for defining transliteration
and transformations of characters ("...for example transliteration rules
between Latin, Greek and Cyrillic, or fallback notation for some frequent
letters...") Note that this cultural specification simply says that
"Transliteration of Cyrillic and Arabic is very different from English
conventions" without giving any specific information about the differences,
and without giving any information at all about how to do a transliteration. In
other words, this provides no concrete information that a software engineer
could use. The sentence "Transliteration of Cyrillic..." therefore
must be removed.
The fallback information is a bit more useful, but does not provide any guidance about when such fallbacks are permitted. Can they be used any time the original letters are not available, or are there restrictions against their use in some circumstances? Are there requirements to keep an original copy of the data so that data is not lost?
More information is needed on fallbacks to make this clause useful.
CD2 TECHNICAL #134
Section: Annex D, Clause 14
Current text:
"The Danish letters <Ø> and <ø> are
often misprinted. . ."
Problem and Action:
Is this still true, or was it true 8-10 years ago
when much of this annex was originally written? The Danish Standards group may
wish to recheck this information and see whether this still is relevant.
The US previously commented on this clause as
follows:
CD1 OBJECTION #32
Section: Annex D, Clause 14 (Character rendition)
Current text:
"The Danish letters <Øand <øare often misprinted. The
stroke in the letters is the problem. If you consider a rectangle box
surrounding the letter, then the stroke should cross from the upper right
corner to the opposite corner."
Problem and Action:
First, is this information still accurate, or was it accurate 7-10
years ago when commercial fonts were not as readily available as they are
today?
A more general problem is how this Clause might be used for other cultural specifications. If rendering issues with a single Danish letter are considered the appropriate information to put here, what might a Traditional Chinese cultural specification include, as it tried to explain all the nuances of rendering traditional Han ideographs? Or an Arabic specification that tried to explain how to render Arabic?
This section as described, and as this example shows, does not scale well beyond languages and cultures that have one or two specific rendering issues. This is inadequate and should be removed.
CD2 TECHNICAL #135
Section: Annex D, Clause 15 (Character inputting)
Current text:
"A proposed general input method is included in
DS/ISO/IEC 9945-1 annex F."
Problem and Action:
This is incorrect. First, the reference to ISO/IEC
9945-1 is obsolete since the standard has been reissued in 2002. Second, it is
incorrect for the 1993 version of ISO/IEC 9945-1 (which includes POSIX.1b).
Annex F in that version is about Portability Considerations, and contains no
information about input methods or Danish.
Annex E (Sample National Profile), and Section E.1 (Profile for Denmark) may be the intended reference, but this also does not seem to include more than cursory information about input methods. The only relevant text seems to be Section E.1.2 (Character Encoding and Display; lines 73-75):
"For input, if the character name is undefined in the current charmap file, the data shall be left untouched (including the <intro> character) and the behavior is implementation defined."
This does not propose a general input method. The Danish Standards organization must correct this reference, since it specifies a incorrect annex in an obsolete version of the standard, and since there seems not to be a description of a Danish input method anywhere in ISO/IEC 9945-1:1993.
CD1 OBJECTION #33
Section: Annex D, Clause 16 (Personal names rules)
Current text:
"Personal names are commonly spelt with the full first name,
while use of initials only is seen also. People are mostly addressed by voice
by their first name. The common address form is the informal "du",
and the more formal "De" is becoming more common. The family name is
never spelt in capital letters only,. . ."
Problem and Action:
This information is vague or useless. How would a software
engineer use the information that "People are mostly addressed by voice by
their first name" (which, by the way, should be their "given
name", not their "first name")? The fact that "De" is
"becoming more common" tells an engineer nothing concrete and so is
useless. These sentences should be removed.
The US notes that "full first name" has been changed to "full first given name" in CD2 15897.
CD1 OBJECTION #34 (re Danish example)
Section: Annex D, Clause 17 (Inflection)
Current text:
"The Danish grammar is defined in
"Retskrivningsordbogen". Danish has more inflections than English,
for example nouns will have 8 forms based on indefinite/definite,
singularis/pluralis and nominative+others/genitive."
Problem and Action:
First, why does the information about Danish inflection compare it
to English? Second, what would a software engineer be expected to do with these
two sentences? Referring someone to a book about overall Danish grammar
probably would have only the most limited value, but at least it points toward
an agreed-upon standard. But why call out inflection separately, since it is
only one part of grammatical rules?
This example simply illustrates why an earlier
OBJECTION calls for removing this clause all together.
Re Irish example:
The Irish example gives a minimal description of the complex
inflection of Irish Gaelic, and refers the user to specific grammar books.
CD2 TECHNICAL #136
Section: Annex D, Clause 23
Current text:
"...Denmark is situated about 54 - 58 degrees
North, and 8 - 15 degrees East. Denmark has an area of about 43.069 km2 and 5,2
mill inhabitants (1995)..."
Problem and Action:
It's curious that Denmark wants to use a
seven-year-old population figure. According to Statistics Denmark 2002 (http://www.dst.dk/imf), the
current population is 5,4 million (rounded up from 5,374 million).
The Danish Standards organization may wish to update its information.
CD1 OBJECTION #35
Section: Annex D, Clause 23 (Coding of national entities)
Problem and Action:
An earlier OBJECTION describes why this clause should be removed.
The information here is such a random collection of factoids that it is
useless.
CD1 OBJECTION #37
Section: Annex D, Clause 27 (Electronic mail addresses) and Clause
28 (Payment account numbers)
Problem and Action:
Remove these sections, as explained in an earlier OBJECTION. These
are not cultural-specific.
CD2 TECHNICAL #137
Section: Clause 28 (Payment account numbers)
In Danish bank account numbers, is there a separator character
between the branch identification code and the bank account number? How long
can the branch account number be?
The textual description of the structure of numbering for Danish Postal Giro accounts does not agree with the example. It is true that there are 7 digits in the example, but there is also a hyphen. Why is the hyphen not mentioned in the textual description? Is it always positioned between the 3rd and 4th digits?
CD1 OBJECTION #38
Section: Annex D, Clause 30 (Man-machine dialogue)
Problem and Action:
Remove this section, as explained in an earlier OBJECTION. This is
too vague to be useful.
38. See response 23.
The Editor's disposition on US comment 23 was:
23. Not accepted. It is commonly accepted good procedures for registries not to delete entries, or possibilities for entries. The proposal here would invalidate already existing entries in the registry.
The Minutes of the WG 20 meeting #22 (N 932) show that this comment was not accepted because "WG20 is not in a position to change the Danish specification."
End of US comments