L2/05-190
ISO/IEC
JTC 1/SC22
Programming
languages, their environments and system software interfaces
Secretariat:
ISO/IEC
JTC 1/SC22 N3922
TITLE:
Disposition
of Comments Report for SC 22 N 3666, ISO/IEC FCD 15897, Information technology
- Procedures for registration of cultural elements (Revision of ISO/IEC 15897:
1999)
DATE
ASSIGNED:
2005-08-02
SOURCE:
Project
Editor (K. Simmonesen)
BACKWARD
POINTER:
DOCUMENT
TYPE:
Disposition
of Comments Report
PROJECT
NUMBER:
STATUS:
This
document has been prepared in response to SC 22 N 3666.
ACTION IDENTIFIER:
FYI
DUE DATE:
DISTRIBUTION:
Text
CROSS
REFERENCE:
N3666
DISTRIBUTION
FORM:
Def
Address
reply to:
ISO/IEC
JTC 1/SC22 Secretariat
Sally
Seitz
ANSI
Telephone:
(212) 642-4918
Fax:
(212) 840-2298
Email:
sseitz@ansi.org
_____________End
of cover sheet, beginning of document______________
ISO/IEC JTC1/SC22/ N3922
2005-05-29
Title:
Disposition of comments on FCD 15897
Source:
Keld Simonsen, project editor
The
ballotted document is SC22 N3586.
SC22
N3666 reflects the outcome of the ballot.
In
addition late comments were received from
agreed
to take into consideration in this disposition of comments.
All
comments taken into account, 8 NBs voted in favour, (2 with comments),
and
4 voted against. With this disposition of comments, one negative vote
was
changed to an affirmative vote (
Comments:
Comments
from ITTF will be accomodated by the editor.
The
occurrances of the words "shall have" and "shall be" will
be changed to
"has"
and "is" respectively in Clause 1 "Scope".
>
10.2.2 Replace "hall" by "shall"
Response:
Accepted. See also US comment 145
>
Section 11 should contain, as the last item: Miscelleaneous requirements
>
not covered elsewhere, as a hint for future i18n developments
Response:
Not accepted, a registry should not be open ended.
If
specified
as a new clause, and they are welcome to propose an amendment
to
the standard.
Comment
accompanying the negative vote from
>
The contents of this document do not reflect a great many changes agreed to be
made
>
to the draft before it was processed, and accordingly the draft cannot be
accepted.
Response:
noted, this will be addressed under the comments from the
>
>
to register cultural elements in terms of the methods described in ISO/IEC TR
14652,
>
which has many technically controversial items.
Response:
The comment is noted.
>
We consider our objections to the previous draft (N 3523) not sufficiently
accomodated.
Response:
Noted. The reference to CEN/TC304 will be removed. see also US comment 28.
>
We propose that a script identifier from ISO 15924 be added in the identifiers
>
for Narrative Cultural Specifications, POSIX locales and other relevant places.
>
This is meant to address cultures that use multiple scripts, eg Cyrillic and
>
Latin scripts in
Response:
Accepted. The comment is accomodated by adding the following text in 13.7:
",
possibly also including script identifiers as specified in ISO 15924,
preceded
by a hyphen.
NOTE:
Guidance on the use of ISO 639, ISO 3166 and ISO 15924 codes for the creation
of
extended language codes can be found in RFC 3066."
A
normative reference to ISO 15924 will be added.
>
Subject: US Comments on FCD Text for the Revision of ISO/IEC 15897
>
From: INCITS/L2
>
Date: 2003-08-27
>
Status: For the consideration of ISO/IEC JTC 1/SC 22/WG 20
>
>
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))
>
* N1010 US comments on the CD2 ballot of ISO/IEC 15897 2003-01-29
>
* N1020, Final Disposition of Comments, 15897 CD2, dated 2003-03-03
>
* N1021, Text of ISO/IEC 15897 for FCD ballot, dated 2003-05-27
>
ISO/IEC documents
>
ISO/IEC Directives, Part 2, Rules for the structure and drafting of
International Standards. 4th.ed. 2001.
>
JTC 1 Directives: ISO/IEC JTC 1. Procedures for the technical work of ISO/IEC
JTC 1. Last Modified: 02/24/2000 07:43:19.
http://www.jtc1.org/directives/main.htm
>
>
Notation:
>
A substantial number of the US comments on the first and second CDs 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 N1021. If text from an earlier comment
is quoted, the original number of the comment (as it appeared in the relevant
WG20 document) is shown, with the prefix "CD1" or "CD2" to
distinguish it from comments on the text of the FCD.
>
>
Organization:
>
US comments on the FCD consist of:
>
* general comments on technical issues and on editorial issues;
>
* technical comments on specific clauses; and,
>
* editorial comments on specific clauses
>
Numbering of US comments on the FCD is continuous.
>
>
GENERAL COMMENTS ON TECHNICAL ISSUES
>
>
FCD General Comment #1 - Technical issue: On use of TR 14652
>
In the DoC on [CD2] General Comment #1, the Editor wrote:
>
Partially accepted. It is not the intention to reference TR 14652 normatively
>
in 15897. However, agreement was reached in JTC1 to publish TR 14652
>
as a TR type 1. Controversies have been resolved as documented in TR
14652,
>
but it is noted that there were issues with a number of specifications.
>
The publication of 14652 has as a Type 1 TR is for JTC 1 to gather experience
>
with the specification and possibly at a later time determine whether
>
a specification based on the TR can be published as an International
>
Standard. Non-normative reference of TR 14652 in 15897 thus enables JTC 1
>
to collect experience with it. 15897 even allows specifications in freeform
>
notation and nonstandard machine readable formats, so it should also
>
allow something that has been approved in JTC 1 as a TR type 1.
>
>
Reference to TR 14652 "controversial" clauses will only be mentioned
alongside
>
other non-normative machine readable formats.
>
>
The US notes that TR14652 will not be referenced normatively in 15897, and that
references to clauses of TR 14652 that are labeled "controversial"
will only be included alongside other non-normative machine-readable formats.
Examples of such other formats are SGML and XML.
Response:
noted.
>
FCD 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.
>
DoC on CD2 N1020
>
Accepted in principle.
>
There is a review and comment process in the registration standard, that
>
ensures a fair process, and this is being enhanced as described elsewhere
>
in these Disposition of Comments. The US should note that the Disposition of
>
Comments was produced by the WG20, and not solely by the editor.
>
>
See FCD TECHNICAL COMMENTS #97, and #102 to #106.
Response:
the response is recorded with the specific US comments
>
FCD General Comment #3 - Technical issue: Technical changes must be justified
>
The US has noticed a number of significant technical differences between the
CD2 and FCD texts, without corresponding NSB comments or WG resolutions to
justify them. Such changes are unacceptable, and must be removed. For
specifics, see these Technical Comments: 13a, 24, 35, 36, 40, 43, 48, 52, 53,
58, 67, 74, 82, 85, 88, 91, 92, 93, 102, 103, 104, 122.
Response:
The response is recorded with the specific US comments
About
unsubstantiated changes, the US acknowledges that the remarks on
unsubstantiated
changes was a misunderstanding.
GENERAL
COMMENTS ON EDITORIAL ISSUES
>
>
FCD General Comment #4 - Editorial issue: Lack of Change Markers
>
The unsubstantiated changes to the FCD text (see FCD General Comment #3) were
not apparent to reviewers because the Editor chose not to indicate where
changes to the text were made. Detecting the differences between the CD2 and
FCD texts required very careful comparison of the two texts, which was
extremely time-consuming.
Response:
accepted in principle. The editor could have provided a supplementary text
for
the FCD ballot indicating changes if that had been requested. Change markers
will
be included in the future drafts.
>
FCD General Comment #5 - Editorial Issue: Poor Organization
>
In the DoC on [CD2] General Comment #3 summarizing the need for improved
organization, the Editor wrote:
>
Accepted in principle.
>
CD2 did a lot of restructuring based on the input in WG20 N945R,
>
but not all changes suggested. As this point will be dealt with
>
in the US comments below, the reponse will be noted there, and
>
not be dealt with further here.
>
>
It is unfortunate that the reorganization suggested in Appendix 2 has not been
incorporated into the FCD (except for the addition of various headings
suggested there).
Response:
noted. The editing was done with guidance from the US members of the
editing
group, but the restructuring that was offered, was not
in
accordance with the decisions in the dispositon of comments for the FCD, as it
made
some
normative text into informative text.
>
FCD General Comment US#6 - Editorial Issue: Uncaught errors
>
CD2 General Comment US#4 commented on the need to use the spell-checking and
grammar-checking features of modern word-processing software in preparing
ballot documents. The Editor accepted this recommendation. However, N1020
contains a number of uncaught errors that suggest failure to spell-check the
document before it was submitted for distribution.
>
The Editor also failed to verify all the URLs in the FCD (see the specific
technical comment on the Introduction for details).
Response:
Noted. The document was spellchecked. URLs were checked, but indeed there are
URLs
that
do not work currently in the document.
>
FCD General Comment US #7 - 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.)."
>
DoC on CD2 N1020
>
Accepted: It was clarified that this applies to the ISO clauses, and not to the
>
narrative sepecifications.
>
>
Any errors in capitalization of clause titles in the FCD will appear as
editorial comments on the individual clauses.
Response:
Noted. This check was done by the editor, if there are still errors, they
will
be dealt with as noted in the response to US comments further below.
>
End of General Comments
>
>
>
>
SPECIFIC TECHNICAL COMMENTS
>
Title
>
>
FCD TECHNICAL #8
>
The title of this standard is
>
Information technology - Procedures for registration of cultural elements
>
but in clause 3 Terms and definitions "cultural element:" is defined
as a synonym for "cultural convention".
>
>
Shouldn't the preferred term be used in the title?
>
Note: There are 16 occurrences of "cultural convention" in the FCD,
but only 5 occurrences of "cultural element" (ignoring use in titles
of referenced documents).
Response:
Not accepted, due to consistency with the title of the
existing
standard the title is retained.
Explanation
of the reuse of the title will be given in a note in clause 1 scope.
Wording
"NOTE The title of this International Standard contains the term
"cultural
elements".
The
preferred term in this International Standard is "cultural
conventions",
but
the term "cultural elements" is retained in the title for consistency
with
earlier versions of this International Standard."
>
Foreword
>
>
FCD TECHNICAL:#9
>
Second paragraph:
>
International Standards are drafted in accordance with the rules given in the
ISO/IEC Directives, Part 3.
>
Change "3" to "2".
>
Rationale: Part 3, published in 1997, has been superseded by Part 2, published
in 2001.
Response:
Accepted
>
FCD TECHNICAL #10
>
Critical issue: Must be resolved to the satisfaction of the US to reverse vote
>
>
DoC on US CD2 TECHNICAL #5 which requested deletion of "and
repertoiremaps".
>
Accepted in principle. However, repertoiremaps are a normative part of 15897
>
itself and will be registerable as such. The sentence will be reworded to:
>
>
This International Standard registers amongst other items
>
Narrative Cultural Specifications and repertoiremaps as defined in this
>
International Standard, POSIX Locales and POSIX Charmaps as defined in
>
ISO/IEC 9945 "POSIX", and other machine parsable cultural
specifications
>
such as ISO/IEC TR 14652 FDCC-sets, charmaps and repertoiremaps, and
>
cultural specifications in SGML.
>
>
The second-last paragraph of the Foreword in the FCD conforms to the
wording given in the DoC on the US comment CD2 TECHNICAL #5, augmented by text
in response to a comment from Germany. It reads:
>
This International Standard registers amongst other items Narrative Cultural
Specifications and repertoiremaps as defined in this International Standard,
POSIX Locales and POSIX Charmaps as defined in ISO/IEC 9945 "POSIX",
and other machine parsable cultural specifications such as ISO/IEC TR 14652
FDCC-sets, charmaps and repertoiremaps, and cultural specifications in SGML or
XML.
>
Change
>
repertoiremaps as defined in this International Standard,
>
to
>
repertoiremaps,
>
Rationale:
>
(a) This FCD is for a procedural standard not a technical standard (as
differentiated in JTC 1 Directives, clause 17.4.1);
>
(b) This FCD does contain a detailed description (in clause 11.1) of the layout
and content of the Narrative Cultural Specification, The content of the
Narrative Cultural Specification is free text, so no technical specification is
needed for the Narrative Cultural Specification.
>
(c) The technical specifications for the content of the repertoiremap are
defined by a separate national, regional, or international standard. This FCD
contains only information on how a repertoiremap that is included in an
application for registration must be formatted (clause 12).
Response:
accepted.
>
Introduction
>
>
FCD TECHNICAL #11
>
Critical issue (ISO requirement): Must be met to satisfy the US and to reverse
vote
>
There is a conflict between DoC on US CD2 TECHNICAL #7 and resulting text in
FCD.
>
The DoC on US CD2 TECHNICAL #7 was "Partly accepted", but no change
to the text was made to address the concern expressed in US CD2 TECHNICAL #7:
>
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".
>
>
>
The only difference between the CD2 text:
>
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/).
>
and the FCD text:
>
The registration will be free-of-charge and the registered cultural elements
will also be freely available on the Internet, via the address
http://www.iso.org/mara/ (the registry will initially be at
http://www.dkuug.dk/cultreg/).
>
is that "network, at" has been changed to "Internet, via",
but this was in response to an entirely different comment, US CD2 EDITORIAL
#80.
>
Furthermore, the ISO URL http://www.iso.org/mara/ specified in the FCD text
produces the error message: Sorry, the URL you've requested doesn't exist on
this server.
>
Delete both URLs as was recommended in CD2 TECHNICAL #7.
>
Rationale:
>
(a) ISO has decreed that the actual URLs of registration agencies shall NOT be
included in International Standards. This decision was made when ISO/IEC 2375
was under development. Therefore, http://www.dkuug.dk/cultreg/) must be deleted
to conform to ISO's decision.
>
(b) Preference is being given to the English language list. ISO maintains
equivalent lists in English and French.
>
(c) Unnecessary repetition of information available elsewhere in the FCD can
result in errors as in this case;
Response:
accepted in principle. The text will remove the references to urls, and say
it
will be freely available on the internet, see clause 6.3.
>
FCD TECHNICAL #12
>
Critical issue (ISO requirement): Must be met to satisfy the US and to reverse
vote
>
In the DoC on US CD2 TECHNICAL #7, the Editor asserted that the dkuug.dk URL
should be mentioned here because "The ISO URLs are hard to browse as they
produce some big lists."
>
This is a specious argument. Only a totally naïve browser user would scroll
down through the list of maintenance agencies and registration authorities.
Using the browser's "find" capability to search for "15897"
takes one straight to the entry for the 15897 Registration Authority.
Response:
Noted. The requirement for reversal of vote is withdrawn by the US.
>
1 Scope
>
>
FCD TECHNICAL #13a
>
Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote
>
CD2, 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.
>
FCD, First paragraph, middle sentence:
>
The cultural specifications may include freeform Narrative Cultural
Specifications as defined in the International Standard, Repertoiremaps as
defined in this International Standard, POSIX Locales and Charmaps conforming
to ISO/IEC 9945, and other machine-parsable specifications such as FDCC-sets,
repertoiremaps and charmaps following the recommendations of ISO/IEC TR 14652,
and cultural specifications in SGML and XML.
>
>
Changes between CD2 and FCD and sources for the changes are:
>
1. "narrative cultural specifications" capitalized,
"conventions" dropped. (Source: None, but required for consistency)
>
2. "as defined in the International Standard" added. (Source: None)
>
3. "Repertoiremaps as defined in this International Standard" added.
(Source: DoC on US TECHNICAL #9, but it conflicts with DoC on US GENERAL
TECHNICAL #1)
>
4. "9945-2" changed to "9945" (Source: US CD2 TECHNICAL #8.
DoC: Accepted.)
>
5. "other machine-parsable specifications such as" added. (Source:
None)
>
6. "cultural specifications in" added. (Source: None)
>
7. "and XML" added. (Source: Germany, Technical Comments, 1st
Accepted.)
Response:
Accepted in principle. Items 2, 6 and 7 has been addressed by
rewording
of the paragraph. First comma replaced by "and".
The
first occurance on "as defined in the International Standard" is
deleted.
"in
SGML" -> formatted using SGML or"
The
WG20 Editing Group agreed on the following rewording of the paragraph for the
FDIS
(rewording
includes responding to US comment 13b):
"The
cultural specifications may include freeform Narrative Cultural Specifications
and
Repertoiremaps
as described in this International Standard, POSIX Locales and Charmaps
conforming
to ISO/IEC 9945, and other machine-parsable specifications such as
FDCC-sets,
repertoiremaps and charmaps following the recommendations of
ISO/IEC
TR 14652, and cultural specifications formatted using SGML or XML.
>
FCD TECHNICAL #13b
>
Change "as defined in the International Standard" to "as
described in this International Standard"
>
Rationale: As given in FCD TECHNICAL #10 above.
Response:
accept. This relates to the second occurrance on repertoiremaps.
>
FCD TECHNICAL #14
>
Critical issue: Must be resolved to the satisfaction of the US to reverse vote
>
Delete "Repertoiremaps as defined in this International Standard,"
>
Rationale:
>
1. Reason for addition given in DoC on US TECHNICAL #9 "Repertoiremaps are
defined normatively in IS 15897" conflicts with statement in DoC on US
GENERAL TECHNICAL #1. The general statement should be generally applicable.
>
2. As given in FCD TECHNICAL #10 on "and repertoiremaps as defined"
above.
Repsonse:
comment withdrawn from the US.
>
FCD TECHNICAL #15
>
Critical issue: Must be resolved to the satisfaction of the US to reverse vote
>
Delete
>
other machine-parsable specifications such as FDCC-sets, repertoiremaps and
charmaps following the recommendations of ISO/IEC TR 14652, and cultural
specifications in SGML and XML.
>
and substitute:
>
other machine processable specifications following the recommendations of
ISO/IEC TR 14652, SGML or XML.
>
Rationale:
>
1. Portions of FCD text not justified by NSB comments or DoC. Substitute text
is modeled on DoC on US CD2 TECHNICAL #6.
>
2. Distinction made between ISO/IEC TR 14652 and SGML and XML conflicts with
DoC on US GENERAL COMMENT #1.
Response:
Accepted in principle. The US was satisfied by the rewording
agreed
upon by the editing group in US comment number 13a.
>
2 Normative references
>
>
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.
>
DoC on CD2 TECHNICAL #14
>
Aceepted in principle. The newest standards will be cited, but some older
>
standards will be cited also, as some registrations refer to the old standards.
>
See FCD TECHNICAL comment on Clause 12 Format of a Repertoiremap.
>
>
FCD TECHNICAL #16
>
ISO 3166 (all parts), Codes for the representation of names of countries.
>
Cited title does not match the title of this standard now shown in the online
ISO Catalogue:
>
Codes for the representation of names of countries and their subdivisions.
Response:
accepted.
>
>
FCD TECHNICAL #17
>
ISO/IEC 8824:1990.
>
N1021 includes these citations:
>
ISO/IEC 8824:1990, Information technology - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1).
>
ISO/IEC 8825:1990, Information technology - Open System Interconnection -
Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1).
>
Update these two citations to agree with the relevant parts of the 1998
editions of these ASN.1 standards.
>
Rationale: See entries for these standards in the ISO Catalogue.
>
Note that Open Systems Interconnection is no longer in the titles.
Response:
accepted - titles will be changed to current titles.
>
3 Terms and definitions
>
>
FCD TECHNICAL #18
>
Critical issue: Must be resolved to the satisfaction of the US to reverse vote
>
Inadequate application of Accepted CD2 comments:
>
In CD2 comments on clauses 3.1 and 3.3 (CD2 TECHNICAL #15 AND #16), the US
requested that the references to clauses in the superseded edition of ISO/IEC
9945 be replaced with those from the 2003 edition. Instead of supplying the
relevant clauses, the Editor substituted the descriptive phrase from the
comment for the (now obsolete) reference to a clause of the POSIX standard.
>
It is hard to understand how the Editor could have so severely misinterpreted
what should be done. Throughout its comments, the US explicitly identifies
replacement text by the instructions "Delete ... and substitute ..."
or "Change ... to ..." This pattern of wording was not used in CD2
TECHNICAL #15 AND #16.
>
The US did not have access to the 2003 edition of the POSIX standard, only to
the version on The Open Group's Web site (which does not show clause
numbering). Had we been able to identify the specific clause number to be
substituted, we would have given the precise replacement text in each of our
comments.
>
A definition must be as precise as possible, and all definitions must be
mutually consistent. Rather than substituting "the locale section"
for "clause 2.5" and "the Character Set section" for
"clause 2.4", the Editor should have demonstrated due diligence by
determining the proper clause to cite in each case. We assumed that the Editor
(who is also the WG20 liaison to SC 22/WG 15) would be able to identify the
appropriate clauses. If in doubt as to the intent of these comments, he should
have consulted the US National Body for guidance.
Response:
accepted in principle. There are no clause numbers in the new 9945, only
section
names. Thus the references are as precise as they can be. References will
be
reworded to include the section name; for example, see the section named
"Locale".
>
FCD TECHNICAL #19
>
Critical issue: Must be resolved to the satisfaction of the US to reverse vote
>
3.1 locale
>
CD2 TECHNICAL #15
>
CD2 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.
>
>
>
FCD text reads:
>
The definition of the subset of a user's information technology environment
that depends on language, territory, or other cultural customs. See the locale
section of the ISO/IEC 9945-1:2002 POSIX standard for a specification of the
locale file format.
>
Cite the exact clause or clauses of ISO/IEC 9945 where the locale file format
is specified.
>
Rationale: For consistency with other definitions.
Response:
accepted in principle. see response to US number 18.
>
FCD TECHNICAL #20
>
Critical issue: Must be resolved to the satisfaction of the US to reverse vote
>
3.3 charmap
>
The definition of charmap in the FCD says:
>
See the Character Set section of the ISO/IEC 9945-1:2002 POSIX standard for a
description of the POSIX Charmap file format, ...
>
as a result of the application of US comment CD2 TECHNICAL #16:
>
This reference is obsolete. Update the text to refer to the Character Set
section in ISO/IEC 9945-1:2002.
>
In implementing the DoC, the Editor substituted the phrase "the Character
Set section" for the obsolete reference "clause 2.4.":
>
Restated comment: Cite the exact clause or clauses of the 2003 edition of
ISO/IEC 9945 where the POSIX charmap file format is specified.
>
Rationale: For consistency with other definitions.
Response:
accepted in principle. see response to US number 18.
>
FCD TECHNICAL #21
>
The definition of charmap in the FCD reads:
>
A text file describing a coded character set. See the Character Set section of
the ISO/IEC 9945-1:2002 POSIX standard for a description of the POSIX Charmap
file format, and clause 5 of ISO/IEC TR 14652 for the description of an
enhanced charmap.
>
Delete the second clause of the second sentence:
>
, and clause 5 of ISO/IEC TR 14652 for the description of an enhanced charmap.
>
so that the definition reads:
>
>
A text file describing a coded character set. See clause [number of the clause
for the Character Set section] of the ISO/IEC 9945-1:2002 POSIX standard for a
description of the POSIX Charmap file format.
>
Number of the clause of ISO/IEC 9945-1:2002 that deals with Character Sets to
be supplied by the Editor (See the comments FCD TECHNICAL #18 and #20).
>
Rationale:
>
The element Terms and definitions is one of the technical normative elements of
a standard (ISO/IEC Directives: Part 2, clause 6.3). Because this is normative
text, items in the bibliography, which is a supplementary informative element
(ibid, clause 6.4), cannot be included. The text referring to "ISO/IEC TR
14652" must be deleted.
Response:
accepted in principle. see response to US number 18. The reference to TR 14652
will be deleted.
>
3.6 cultural element
>
FCD TECHNICAL #22
>
DoC on US CD2 TECHNICAL #18:
>
Accepted. It [cultural element] will be defined as a synonym for "cultural
convention".
>
Text of clause 3.6 in FCD:
>
3.6
>
cultural element
>
A synonym for a cultural convention.
>
Delete clause 3.6, and renumber the following clauses 3.7 to 3.11 as 3.6 to
3.10.
>
In clause 3.6, add "cultural element" (in regular typeface) on a
separate line between the preferred term "cultural convention" and
the definition.
>
Rationale: See example in ISO/IEC Directives: Part 2, clause C.3.3. This clause
dictates that synonyms are not treated as independent terms, but are included
in the clause that defines the preferred term.
Response:
accepted.
>
3.7 cultural specification
>
CD2 TECHNICAL #17
>
Insert the following text between "Repertoiremap" and the comma which
follows it:(except an ISO/IEC TR 14652 Repertoiremap)
>
DoC on CD2 TECHNICAL #17 states:
>
Partially accpeted, as in the response to US comment 9.
>
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.
>
Text of DoC on US comment #9 reads:
>
Partially accepted, as noted in the response to US comment 1. Repertoiremaps
>
are defined normatively in IS 15897 so they will be mentioned after the
>
Narrative cultural specifications, and once more with 14652, but the
>
text will indicate that the 14652 registration is with the same status
>
as SGML and XML specifications, as other machine prossesble specifications.
>
>
Definition of cultural specification in FCD reads:
>
Either a Narrative Cultural Specification, a POSIX Locale, a FDCC-set, a POSIX
Charmap, an ISO/IEC 15897 Repertoiremap, an ISO/IEC TR 14652 Repertoiremap, or
other machine-processable description of cultural conventions such as ISO/IEC TR
14652 FDCC-sets, Charmaps or Repertoiremaps, or cultural specifications in SGML
or XML.
>
FCD TECHNICAL #23
>
Critical issue: Must be resolved to the satisfaction of the US to reverse vote
>
Delete "an ISO/IEC 15897 Repertoiremap"
>
Rationale:
>
1. This FCD does not include a specification for a repertoiremap. Clause 12
merely defines the format of a repertoiremap. ISO/IEC 15897 is a procedural
standard; the specification of a repertoiremap must come from a technical
standard.
>
2. See also US comments on Foreword and Introduction.
Response:
accepted in principle. The wording will be changed to "a
Repertoiremap".
>
FCD TECHNICAL #24
>
Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote
>
Insert "Charmap, a" between "14652" and
"Repertoiremap"
>
Rationale: Restores text of CD2. (Removal of this normative text was not
proposed in any NSB comment.)
Response:
accepted in principle. The text "ISO/IEC 15897 Repertoiremap, an ISO/IEC
TR 14652 "
will
be deleted. The change was done to not reference 14652 things in a
normative
category,
and TR 14652 charmaps are now referenced on level with XML.
Based
on the changes resulting form the DoC on US comments #23 and #24,
The
definition of "cultural specification" now is:
Either
a Narrative Cultural Specification, a POSIX Locale, a POSIX
Charmap,
a Repertoiremap, or other machine-processable description of
cultural
conventions such as ISO/IEC TR 14652 FDCC-sets, Charmaps or
Repertoiremaps,
or cultural specifications in SGML or XML.
>
6.3 Identity [of the Registration Authority]
>
>
FCD TECHNICAL #25
>
Critical issue (ISO requirement): Must be met to satisfy the US and to reverse
vote
>
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.
>
DoC on US CD2 TECHNICAL #21
>
Not accepted. See response to US comment 7.
>
DoC on US CD2 TECHNICAL #7 states:
>
Partly accepted. It does not hurt, and helps the reader that the dkuug.dk URL
>
is mentioned in the specification. The ISO URLs are hard to browse
>
as they produce some big lists.
>
>
The US reiterates CD2 TECHNICAL #21.
>
Rationale: See FCD TECHNICAL #11 comment on Introduction. The Editor is
refusing to obey an editorial decision of ISO.
Response:
Withdrawn by the US.
>
7.1 Identity [of the Sponsoring Authority]
>
>
List of who may submit applications for registration now is:
>
a) Any Member Body of ISO/IEC JTC1, for applications limited to the territory
or territories for which they have authority;
>
b) Any Member Body or Associated Member Body of CEN, for applications limited
to the territory or territories for which they have authority;
>
b) CEN/TC304 for applications related to the region of Europe;
>
c) ISO/IEC JTC 1 and its Subcommittees and Working Groups, for any
applications;
>
>
FCD TECHNICAL #26
>
CD2 TECHNICAL #24 proposed the inclusion of liaisons in the equivalent of item
(a). The DoC on CD2 TECHNICAL #24 stated: Liaisons do not have any authority,
and will not be included.
>
This disposition conflicts with the provisions of clause 3.3.4.2 of the JTC 1
Directives, where Category A liaisons are defined as:
>
Organizations which make an effective contribution to and participate actively
in the work of JTC 1 or its SCs for most of the questions dealt with by the
committee.
>
and Category C liaisons are defined as:
>
Organizations which make an effective technical contribution and participate
actively at the WG or project level of JTC 1 or its SCs.
Response:
Not accepted. Withdrawn by the US.
>
FCD TECHNICAL #27
>
b) Any Member Body or Associated Member Body of CEN, for applications limited
to the territory or territories for which they have authority;
>
The wording of item b does not agree with CEN's categories for membership and
participation in technical work:
>
* CEN National Members are "the national standards bodies of
<list>". ..." The Members develop and vote for the ratification
of European Standards."
>
Source: http://www.cenorm.be/aboutcen/whatis/membership/members.htm
>
* Associates are "broad-based European organizations representing
particular sectors of industry as well as consumers, workers, and small and
medium-sized enterprises. ... They participate in the General Assembly (without
voting rights), the Administrative Board when policy matters are being
discussed, the Technical Board and any other technical body."
>
Source: http://www.cenorm.be/aboutcen/whatis/membership/associates.htm
>
* Affiliates are "the national standards bodies of Central and Eastern
European countries which can in principle become members of the Union or EFTA,
and which therefore can become full National Members of CEN on fulfilment of
certain criteria, most importantly the adoption of European Standards as
national standards.
>
They may participate in the General Assembly and in technical bodies. "
>
Source: http://www.cenorm.be/aboutcen/whatis/membership/affiliates.htm
>
Make the following changes to item (b):
>
Delete:
>
Any Member Body or Associated Member Body
>
and substitute:
>
Any National Member, Associate, or Affiliate
>
Rationale: To agree with current CEN terminology. The US assumes that
"Associate" is meant by "Associated Member Body". The US
sees no reason to exclude CEN Affiliates, which are national standards bodies
and would therefore be eligible under item (a) in any case.
Response:
accepted.
>
FCD TECHNICAL #28
>
The Netherlands commented on CD2:
>
> 2 - The reference to CEN TC304 (see clause 8.1) should be removed.
>
and the Editor replied in the DoC (N 1020):
>
Noted. No acction taken, pending the determination of the future status of
TC304.
>
As of June 2002, CEN TC304 was declared dormant by BT/TCMG on behalf of BT
except for 3 specific work items. For details, see
http://www.cenorm.be/isss/Projects/CDSG/docs/CDSG03_03BTres12_2002.pdf
>
>
The 3 specific work items were described in Programming for Cultural Diversity
Consensus-Building (dated 2002-08-14 and available as SC22/WG20 N974), page 49:
>
As it stands, the only definite ongoing work would be the three following work
items, and their remaining life cycle is very short, as they are near their
completion stages:
>
1. European Fallback Rules (ch. to TR) 26.10.2
>
2. European extension to ISO repertoire of OCR-B (EN) (built on Test results)
26.15
>
3. Revision work on EN 1923 (Inclusion of euro sign and missing European
letters in new TS 1923)
>
TC 304 no longer appears in the CEN pull-down lists of Technical Committees.
(http://www.cenorm.be/standardization/tech_bodies/cen_tcs.htm , last updated
2003-05-12). All of the other CEN/ISSS Technical Committees (as listed at
http://www.cenorm.be/isss/TC/Default.htm, last update 2003-07-04) appear on the
pull-down lists.
>
Given these developments, the US supports the comment of the Netherlands.
Response:
accepted.
>
7.2 Responsibilities [of the Sponsoring Authority]
>
>
Item c
>
FCD TECHNICAL #29
>
c) in the case of a POSIX Locale or Narrative Cultural Specification, to ensure
that Narrative Cultural Specification and the derived POSIX Locale are not in
contradiction.
>
Relocate this item in clause 13 Rules for Cultural Specifications as follows:
>
Delete item c) of clause 7.2 and redesignate remaining items of clause 7.2 as
c) through g).
>
Insert a new clause between clauses 13.3 and 13.4. The new clause is designated
13.4; existing clauses 13.4 to 13.7 are redesignated 13.5 to 13.8. Text of the
new clause:
>
If an application for registration includes a POSIX Locale as well as a
Narrative Cultural Specification, the POSIX Locale shall not contradict the
Narrative Cultural Specification.
>
Rationale: This is a rule for the Cultural Specification, so it belongs in
clause 13. Three bodies have responsibility for seeing that the rules for
Cultural Specifications are obeyed: (1) the Sponsoring Authority which submits
the application for registration, and (2) the Registration Authority and (3)
the RA-JAC which both review applications.
>
* The responsibility of the Sponsoring Authority is specified in item b which
references clause 13.
>
* The requirements for review by the Registration Authority is specified in
clause 15.5 which references various parts of clause 13.
>
* The requirements for review by the RA-JAC are specified in clause 15.6.
>
Note: Relocating item c to clause 13 will satisfy the US concerns expressed in
CD1 TECHNICAL #113.
Response:
accepted in principle. Response to US comment 32 addresses this.
>
Item d
>
FCD TECHNICAL #30
>
DoC ON CD2 TECHNICAL #26
>
Accepted in principle. The copyright may be retained, but the rights on copying
>
and modification needs to be relinguished. See also German comments.
>
Item (d) in the FCD now is:
>
d) if any material in an application is under copyright, to assure that free
distribution of the Cultural Specification is permitted.
>
Unacceptable wording. The Sponsoring Authority must supply a document in which
the copyright holder grants permission for the inclusion of its copyrighted
material in the Cultural Specification and the distribution of the copyrighted
material as part of the Cultural Specification. Furthermore (in accordance with
the German comment), there should be no payment due to the copyright holder
when the material under copyright is distributed.
>
>
Rationale:
>
1. Agreement with ISO/IEC 2375:2003.
>
2. To protect JTC 1 from accusations of copyright infringement, there must
always be documented permission from the copyright holder for the use and
distribution of copyrighted material included in a registered cultural
specification.
>
>
Note: Some of the registrations in
http://anubis.dkuug.dk/cultreg/registrations/chreg.htm appear to come from
copyrighted sources.
>
>
German comment from N 1020
>
> 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)
>
>
Accepted, will be changed to allow the free distribution of the specification,
>
with words as in annex A.
>
>
Both are needed. (a) Written permission to redistribute copyrighted material.
(b) Ability to redistribute the copyrighted material without having to pay a
fee to the copyright holder.
Response:
accepted in principle. The US will work with the editor on
wordings
to address both requirements.
>
8.2 Responsibilities
>
>
FCD TECHNICAL #31
>
Text of item (b):
>
b) if any material in a Cultural Specification is under copyright, to assure
that free distribution of the Cultural Specification is permitted;
>
Inadequate wording. See also CD2 TECHNICAL #26
>
>
# Copyright clearance
>
>
Dealt with in new item added to clause 8.2 that makes the Sponsoring Authority
responsible for obtaining copyright clearance.
>
Weakened in Editor's rewording. Source of Information is now responsible for
obtaining the copyright clearance. Sponsoring Authority is responsible for
making sure that any copyrighted material in an application is accompanied by
documented clearance for use and reproduction.
Response:
Accepted in principle, see response to US comment 30.
>
CD2 clause 9 Rules for applications
>
>
FCD TECHNICAL #32
>
Critical issue: Must be resolved to the satisfaction of the US to reverse vote
>
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.
>
DoC on CD2 N1020
>
The response to this is recorded in Appendix 2.
>
The DoC on Appendix 2 (in N 1020) was only:
>
Accepted in principle. Headings will be added.
>
The US considers this to be an inadequate response. Appendix 2 should have been
"Accepted" (not ignored via "Accepted in Principle")
because it is better organized than the existing clauses.
Response:
accepted in princple. The US NB will work with the editor to complete the
reorganization
in accordance with the suggestions made in
US
comments to CD2 appendix 2 in WG20 N1020.
>
FCD clause 9 The Registration Authority's Joint Advisory Committee
>
Clause 9.1 Membership
>
>
FCD TECHNICAL #33
>
Critical issue: Must be resolved to the satisfaction of the US to reverse vote
>
Was CD2 TECHNICAL #58, item 2
>
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.
>
DoC on CD2 TECHNICAL #58
>
Accepted in principle. The title will be changed. The obligation of the JAC to
>
respond to RA will be worded in another way to emphasis
>
this as an obligation of the JAC.
>
FCD text:
>
The Registration Authority may request the RA-JAC to provide expert technical
advice on comments.
>
Delete this text (last paragraph of clause 9.1).
>
Rationale:
>
1. The paragraph is in the wrong place. Rewording it does not correct the
error.
>
2. The information also appears in clause 15.13 (which is the correct place for
it).
Response:
accepted.
>
Clause 9.2 Appointment
>
>
Clause 9.2, first paragraph
>
FCD TECHNICAL #34
>
Critical issue: Must be resolved to the satisfaction of the US to reverse vote
>
FCD text: (unchanged from CD2):
>
The subcommittee responsible for maintaining this standard shall appoint the
members of the RA-JAC, except for the RA representative, which is appointed by
the RA.
>
US request in CD2 TECHNICAL #60 to delete "except for the RA representative,
which is appointed by the RA" was rejected.
>
Not accepted. It is normal that an organization, such as the RA,
>
appoints its own representative. "except for the representative
>
of the RA" will be added to the second sentence.
>
The text in the first paragraph of clause 9.2 of the FCD is unacceptable to the
US unless "except for the RA representative, which is appointed by the
RA" is deleted.
>
Rationale: It is unclear whether the representative of the Registration
Authority (RA) is appointed by SC22 (based on a nomination by the RA), or
whether the person responsible for the maintenance of the Registry is ex
officio the representative of the RA.
>
This issue should be clarified, so that the text can reflect the decisions of
JTC 1 and SC22.
>
In the absence of authoritative information, the phrase "except for the RA
representative, which is appointed by the RA." should be deleted.
>
Since the text is unchanged from the CD2, these additional reasons still apply:
>
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:2003. 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".
Response:
withdrawn by the US.
>
Clause 9.2, second paragraph
>
FCD TECHNICAL #35
>
Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote
>
FCD text:
>
The subcommittee responsible for maintaining this standard shall appoint or
confirm the members of the RA-JAC at its plenary meetings, except for the
representative of the RA.
>
Delete the comma following "meetings" and the final clause of the
paragraph:
>
except for the representative
of the RA
>
Rationale: Addition of the final clause not supported by a NB comment.
>
Note: The US notes that the Editor also changed "meeting" to
"meetings". The US has no objection to this editorial change
(although singular is also permissible English usage here, implying "each
of" its plenary meetings).
Response:
withdrawn by the US.
>
Clause 9.3 Responsibilities
>
>
FCD TECHNICAL #36
>
Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote
>
In CD2 TECHNICAL #63, the US proposed substitution of the following text, which
was Accepted:
>
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>
>
>
Although the text supplied by the US was "Accepted" the Editor made
the following changes:
>
1. Omitted the final sentence:
>
In addition, the RA-JAC may added comments to a registration.
>
2. Added another item (not justified by NSB comment nor WG 20 resolution):
>
to submit comments, that four fifths of the RA-JAC agree upon, to a
registration for publication together with the registration
>
>
The final sentence in the text proposed in CD2 TECHNICAL #63 has a grammatical error,
and should have been:
>
In addition, the RA-JAC may add comments to a registration.
Response:
accepted in principle. In addition a text is added in 15.13 to require a
four/fifths majority
for
such comments.
>
>
Clause 10.1 Types of Cultural Specifications
>
>
first paragraph:
>
FCD TECHNICAL #37
>
Item 4 in the list reads:
>
4. POSIX Repertoiremap
>
Delete "POSIX"
>
Rationale: POSIX has never defined repertoiremaps, so wording is incorrect.
Response:
accepted.
>
FCD TECHNICAL #38 -- #40
>
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.
>
DoC on CD2 N1020
>
Not accepted. See response to US comment 1. The reference to 14652
>
repertoiremaps will
>
be put in a note, saying that this format is equivalent to 15897
repertoiremaps.
>
>
Corresponding text in FCD (clause 10.1, paragraph 4 and accompanying note)
reads:
>
Type 4 is for Repertoiremaps defined in this International Standard (clause
12).
>
Note: As far as Repertoiremaps according to ISO/IEC TR 14652 is also in
accordance with clause 12, these can also be registered as Type 4.
Response:
there is no US comments 38.
>
FCD TECHNICAL #39
>
Critical issue: Must be resolved to the satisfaction of the US to reverse vote
>
Delete
>
defined in this International Standard (clause 12)
>
and add a second sentence:
>
Clause 12 defines the format of a repertoiremap included in an application for
cultural registration.
>
Rationale: This FCD is for a procedural standard, which cannot define technical
specifications for a repertoiremap.
Response:
accepted
>
FCD TECHNICAL #40
>
Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote
>
Remove the note.
>
Rationale:
>
1. The note is redundant because any repertoiremap that is part of an
application for registration, whether it is created according to ISO/IEC TR
14562 or not, must conform to clause 12.
>
2. The note is unsubstantiated as it was not specified in US comment CD2
TECHNICAL #29.
>
Note: The layout of the note does not conform to ISO/IEC Directives: Part 2,
clause 6.5.1.
>
Response:
partially accepted, this was specified as response in CD2 US comment 29.
the
layout will be corrected as requested.
>
10.2 Relations between registration types
>
>
FCD TECHNICAL #41
>
Critical issue: Must be resolved to the satisfaction of the US to reverse vote
>
CD2 TECHNICAL #30
>
CD2 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.
>
DoC on CD2 N1020
>
Partially accepted. Repertoiremaps ar a part of this standard. See
>
also response to US comment 1. Wording of "one or more" will be
added.
>
Corresponding text in FCD (clause 10.2.2) reads:
>
The POSIX locale hall specify appropriate aspects of a Narrative Cultural
Specification in formal POSIX syntax. The POSIX Locale shall refer to the
ISO/IEC 15897 Repertoiremap being used, and should also list one or more POSIX
Charmaps that it can use.
>
Revise the second sentence as follows:
>
The POSIX Locale should list one or more POSIX Charmaps that it can use.
>
Rationale:
>
ISO/IEC 15897 is a procedural standard, so cannot specify the technical details
of a repertoiremap. (Clause 12 describes only the layout for a repertoiremap
included in an application for registration.)Note: The typographical error in
clause 10.2.2 is addressed in a separate editorial comment.
Response:
accepted in principle. Text will be changed to:
"The
POSIX locale shall specify appropriate aspects of a Narrative Cultural
Specification
in formal POSIX syntax. The POSIX locale shall refer to either
one
or more POSIX charmaps it can use, or to a Repertoiremap."
>
Clause 10.2.3
>
FCD TECHNICAL #42
>
Delete:
>
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.
>
and substitute:
>
A POSIX Charmap may refer to POSIX locales, Narrative Cultural specifications,
or Repertoiremaps that it uses, but such references are not required."
>
Rationale:
>
The second sentence in the current FCD text requires that a repertoiremap be
identified in a POSIX charmap registration. This is incorrect, since (a) POSIX
does not define repertoiremaps, and (b) this procedural standard can only
describe the format of repertoiremaps.
Response:
accepted.
>
Clause 10.2.4
>
FCD TECHNICAL #43
>
Critical issue: Must be resolved to the satisfaction of the US to reverse vote
>
Current text:
>
The ISO/IEC 15897 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.
>
Corresponding text in CD2:
>
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.
>
Remove "ISO/IEC 15897"Rationale:
>
1. This standard is a procedural standard and so cannot specify the technical
details for a repertoiremap.
>
2. The addition of "ISO/IEC 15897" is unsubstantiated by any NB
comment. The WG 20 decision on the disposition of CD2 General Comment #1 does
not apply here because this clause deals only with repertoiremaps.
Response:
accepted.
>
Clause 10.2.5
>
FCD TECHNICAL #44 -- #45
>
DoC on CD2 TECHNICAL #31
>
Partially accepted. See response to US comment 1. The reference for
>
repertoiremaps will be clarified to mean the 15897 repertoiremap.
>
The first "shall" will be changed to "may".
>
Corresponding text in FCD (clause 10.2.5) reads:
>
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 may refer to a corresponding Narrative Cultural
Specification. In case of a TR 14652 FDCC-set it shall refer to the ISO/IEC
15897 Repertoiremap being used, and should also list one or more Charmaps that
can be used.
>
>
FCD TECHNICAL #44
>
Critical issue: Must be resolved to the satisfaction of the US to reverse vote
>
Delete the sentence:
>
In case of a TR 14652 FDCC-set it shall refer to the ISO/IEC 15897
Repertoiremap being used, and should also list one or more Charmaps that can be
used.
>
and substitute:
>
A TR 14652 FDCC-set may refer to the Repertoiremap being used, and should also
list one or more Charmaps that can be used.
>
Rationale:
>
1. ISO/IEC 15897 is a procedural standard, so cannot specify the technical
details of a repertoiremap.
>
2. Stylistic improvements to clarify instruction.
Response:
accepted.
>
FCD TECHNICAL #45
>
Critical issue: Must be resolved to the satisfaction of the US to reverse vote
>
ERROR: In the first sentence, the second (not the first) "shall" has
been changed to "may".
>
To reduce the complexity of this sentence, the US proposes that this sentence
be reworded as follows:
>
Some aspects of a Narrative Cultural Specification may be specified in formal
syntax as a TR 14652 FDCC-set, or other machine-parsable cultural
specification, which shall refer to the corresponding Narrative Cultural
Specification.
>
Rationale: As currently worded, it is unclear as to what the referent of
"it" is.
Response:
accepted in principle, "shall" is changed to "may" in the
last dependent
clause,
that is "... which may refer to ...".
>
Clause 10.2.6
>
FCD TECHNICAL #46
>
Critical issue: Must be resolved to the satisfaction of the US to reverse vote
>
Text in FCD (clause 10.2.6) reads:
>
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 ISO/IEC 15897 Repertoiremap being used, and may refer to the
FDCC-set or the Narrative Cultural Specifications using it.
>
Delete the second sentence:
>
In case of a Charmap it shall refer to the ISO/IEC 15897 Repertoiremap being
used, and may refer to the FDCC-set or the Narrative Cultural Specifications
using it.
>
and substitute:
>
A Charmap may refer to the Repertoiremap being used, and may refer to the
FDCC-set or the Narrative Cultural Specifications using the Charmap.
>
Rationale:
>
1. ISO/IEC 15897 is a procedural standard, so cannot specify the technical
details of a repertoiremap.
>
2. Since Repertoiremaps are only a controversial part of ISO/IEC14652, it's
incorrect to require that a Charmap "shall refer to the [ISO/IEC 15897]
Repertoiremap being used."
>
3. Consistent with the corresponding text of CD2, clause 9.2.6.
>
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.
>
4. Stylistic improvements to clarify instruction. Also corrects absence of a
comma between "Charmap" and "it".
Response:
accepted.
>
>
Clause 11
>
>
FCD TECHNICAL #47
>
In response to US CD1 OBJECTION #22, the Editor incorporated the text of Annex
G into CD2 clause 9.4, including the duplicative list of items (that are listed
and described in more detail elsewhere in the standard).
>
US comment CD2 TECHNICAL #34 explained:
>
The intent of the US comment [CD1 #22] was to eliminate double look-up. Instead
of checking Annex G, the user must now check clause 9.4. The problem persists.
>
The DoC on this comment was::
>
Accepted in principle. The US NB is invited to provide revised
>
text for the consideration of the editor.
>
In Appendix 2 of the US comments on CD2, the US provided substitute text that
eliminated the problem. The DoC on Appendix 2 (in N 1020) was:
>
Accepted in principle. Headings will be added.
>
Since the Editor invited the US to supply text to fix the problem, but did not
use the text that was supplied, the US can only assume that the proposed text
was overlooked. We therefore describe the necessary changes here:
>
Delete the first two paragraphs of Clause 11 and their dependent lists.
>
Rationale: Repeats information available in more detail in the same clause.
Response:
accepted in principle, see response to US comment 32.
>
Clause 11.1 Contents of Narrative Cultural Specification
>
>
Introductory paragraph, first and second sentences:
>
Although the text proposed by the US was accepted in the DoC (N1020), different
text appears in the FCD:
>
Guidelines for the contents of the Narrative Cultural Specification are
described informally in some detail in the following. The information builds on
information from the POSIX Base Definitions standard (ISO/IEC 9945-1:2002) and
the Nordic Cultural Requirements on Information Technology Summary Report.
>
FCD TECHNICAL #48
>
Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote
>
Delete the following cases of added text: that were not in the US-supplied text
that was Accepted. They are unsubstantiated by any other NSB comment or a WG20
resolution.
>
(a) "Guidelines for"
>
Rationale: Redundant.
>
(b) "informally"
>
Rationale: Inappropriate. This text is normative, so is hardly informal.
Response:
accepted. Additionally clause 11.1 will be marked as
Informative,
which was its intent, as it was derived from informative Annex G.
>
FCD TECHNCIAL #49
>
"clause" is missing from the end of the first sentence.
>
Rationale: Appears in Accepted text.
Response:
accepted. "in the following" will be changed to "in this
clause"
>
FCD TECHNCIAL #50
>
In the second sentence, delete:
>
The information
>
and substitute
>
The specification
>
Rationale: "specification" appears in Accepted text.
"information builds on information" is not satisfactory.
Response:
accepted
>
FCD TECHNCIAL #51
>
Critical issue (ISO requirement): Must be met to satisfy the US and to reverse
vote
>
New clause: Mandatory clauses
>
>
Insert a new subclause numbered 11.1.1, with the heading "Mandatory
clauses", between the Note and the heading "Clause 1: Alphanumeric
deterministic ordering".
>
Text of subclause:
>
The format of a Narrative Cultural Specification shall contain the clauses
(numbered 1-6) specified below. These clauses are POSIX categories. The
Narrative Cultural Specification should be accompanied by a corresponding POSIX
Locale specification. 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:
>
Rationale: Corresponds to heading "Optional clauses" called for
according to ISO Directives (see New clause: Optional clauses below).
Response:
accepted.
>
FCD TECHNCIAL #52
>
Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote
>
Clause 3: Numeric formatting
>
Current text:
>
This clause describes how numbers are formatted (for input and output),
including the format of the decimal point and the thousands gouping separator.
The specification is intended to be used by all programs that produce numbers,
including table generating programs where multiple numbers are displayed together,
and the specification is also meant for numbers that do not have fractions.
Special considerations for how numbers should be formatted in narrative text
and other numeric formatting that cannot be handled by the POSIX standard may
be specified in Clause 20. This is a POSIX category.
>
All of the text between the first and last sentences is new in the FCD. In its
comments on CD2, the Netherlands NB asked for more explanatory text for this
and other clauses, and that comment was accepted with the note:
>
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...
>
>
Accepted in principle. "Deterministic ordering" and other possibly
>
unclear terms will be will be explained more fully. ...
>
>
Remove the sentence:
>
The specification is intended to be used by all programs that produce numbers,
including table generating programs where multiple numbers are displayed
together, and the specification is also meant for numbers that do not have
fractions.
>
>
Rationale:
>
That DoC does not support the new, detailed description of how this clause
supports the definition of numeric formatting. There is no agreement within
WG20, for example, that this clause is intended for table generating programs,
or that it is meant for numbers that do not have fractions.
Response:
accepted.
>
FCD TECHNCIAL #53
>
Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote
>
Clause 5: Date and time conventions
>
Current text, fifth and sixth sentences:
>
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, and
the abbreviated date formats should be of constant length for them to be used
in lists. The long formats should be usable in narrative text such as letters.
>
Remove these two sentences.
>
Rationale:
>
Addition of the text has not been sanctioned by any NSB comment or WG20
resolution.
Response:
withdrawn by the US. The text was added to accomodate comments from The
Netherlands.
>
FCD TECHNCIAL #54
>
Critical issue (ISO requirement): Must be met to satisfy the US and to reverse
vote
>
New clause: Optional clauses
>
>
Delete the sentence:
>
The following clauses are not directly related to POSIX Locales, and they are
optional:
>
preceding "Clause 7: National or cultural Information Technology
terminology".
>
In its place, insert a new subclause numbered 11.1.2, with the heading
"Optional clauses", above "Clause 7: National or cultural
Information Technology terminology".
>
Text of subclause:
>
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:
>
Rationale:
>
1. The boldface sentence is a hanging paragraph which "should be avoided
since reference to them is ambiguous." (ISO/IEC Directives, Part 2, clause
5.2.4)
>
2. From US CD2 TECHNICAL #48
>
The US notes that the optional nature of these data elements
("Clauses") has been specified immediately before Clause 7. We prefer
the approach used in Appendix 2, where the required and optional data elements
("Clauses") are separated into distinct numbered clauses. The US
preference is also in accordance with the ISO/IEC Directives regarding the need
for the explicit numbered references for the text of a standard.
Response:
accepted.
>
Clause 8: National or cultural profiles of standards
>
FCD TECHNICAL #55
>
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..."
>
DoC on CD2 TECHNICAL #116
>
Partly accepted. The 1993 standard will be referenced.
>
FCD text:
>
In this clause profiles of standards can be listed, for example, OSI national
profiles, or profiles of the POSIX standards. See the POSIX ISO/IEC 9945-2:1993
standard Annex G for an example.
>
Remove this sentence.
>
See the POSIX ISO/IEC 9945-2:1993 standard Annex G for an example.
>
>
Rationale:
>
1. The 1993 edition is obsolete, and the material in Annex G is not included in
the new POSIX standard, so references to this must not be cited in normative
text.
>
2. Because the 1993 edition is obsolete, it cannot be obtained from ISO, so it
is a disservice to the users of this standard to cite it.
Response:
not accepted. It is permissable to refence older standards,
this
is done by referencing the standard by year of publication.
Note
that clause 11.1 is now informative only.
>
Clause 10: Sorting and searching rules
>
FCD TECHNICAL #56
>
CD2 text:
>
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.
>
FCD text:
>
This clause is for specifying sorting and searching rules that cannot be
specified with POSIX specifications, such as ISO/IEC 14651 specifications,
non-deterministic ordering, pre-handling and post-handling of records, such as
how to split a record into sorting fields, and rules for common words like a, the
which may be ignored when comparing or searching. Also sound based matching
rules may be described here. What can be accomplished deterministically with
POSIX should be described in clause 1.
>
The FCD text has not been sanctioned by any NSB comment or WG20 resolutions, so
the CD2 text must be restored.
Response:
withdrawn by the US. The text was added to accomodate comments from The
Netherlands.
>
Clause 11: Transformation of characters
>
FCD TECHNICAL #57
>
The DoC on US CD1 Objection #49 (requesting removal of this clause) was:
>
49. Not accepted. There are already many quite elaborate transliteration specs
in 14652 style.
>
In CD2 TECHNICAL #118, the US commented:
>
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.
>
DoC on CD2 TECHNICAL #118
>
Accepted. A reference will be given.
>
FCD text:
>
This clause describes transliterations and transformations of characters, 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. Examples of transliteration
and fallback specifications in a syntax described in an earlier draft of
ISO/IEC TR 14652 may be found in the bibilographic reference 4.
>
The US recommends that Clause 11 Transformation of characters be annotated
"Not recommended."
>
Rationale:
>
1. The justification for the DoC on US CD1 Objection #49 is false. No elaborate
transliteration specs "in 14652 style" have been shown to exist.
>
2. Inclusion of item 4 in the bibliography is not warranted because the
examples cited do not provide the required model for what should be in this
clause.
Response:
not accepted. The examples specified do give specifications
of
transliteration and fallbacks.
>
Clause 13: Use of special characters
>
FCD text:
>
This clause describes the use of special characters, that is characters that
are not letters, ideographics or syllables or other characters used to write
words of a language, digits or control characters. Examples of special
characters are quotation marks, abbreviation marks, and punctuation marks. 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.
>
Corresponding CD2 text:
>
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.
>
US CD2 TECHNICAL #120 stated:
>
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.
>
The DoC on US CD2 TECHNICAL #120 was merely:
>
Accepted.
>
>
FCD TECHNICAL #58
>
Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote
>
The following changes were made to the text of Clause 13 between the CD2 and
the FCD:
>
1. Here use of special characters was changed to This clause describes the use
of special characters
>
This change was in response to US comment CD2 EDITORIAL #103 which was
Accepted.
>
2. The following text was added:
>
that is characters that are not letters, ideographics or syllables or other
characters used to write words of a language, digits or control characters.
>
To be added to the FCD, the new wording should have been included in the DoC,
and should have represented either a recommendation from a National Body or
wording formulated at the WG20 meeting in February. None of these requirements
were met.
>
Response:
withdrawn by the US. The text was added to accomodate comments from The
Netherlands.
>
FCD TECHNICAL #59
>
Omit "control characters" from the current definition of
"special characters."
>
Rationale: Control characters are a feature of information technology, not a
feature of writing systems (which the other listed items appear to be).
>
Note: If control characters are also to be excluded, they should be listed
separately, and it should be explained why they are excluded. (Perhaps because
world-wide interoperability of information technology requires the use of
control characters defined in culturally-neutral International Standards.)
Response:
accepted in princple. The sentence is rewritten to clarify that special
charcters
exclude control characters. See also comment 60.
>
first sentence
>
FCD TECHNICAL #60
>
Insert "or that are not" between "language," and
"digits", so that the sentence reads:
>
This clause describes the use of special characters, that is characters that
are not letters, ideographics or syllables or other characters used to write
words of a language, or that are not digits ...
>
Rationale: As currently written, the "other characters" that are
excluded are those "used to write ... digits or control characters."
The intent is to exclude the digits themselves (Re control characters, see
preceding comment.)
Response:
accepted.
>
third sentence
>
FCD TECHNICAL #61
>
Lack of clarity in the sentence:
>
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
>
1. Should number signs in general be avoided? Or is the issue that there are
culture-specific signs used to represent the word "number" (for
example, # in the U.S.), and the number sign appropriate to a particular
culture should be used?
>
2. The US believes that "pilcrow sign" here should be "signs for
paragraphs and sections." There is no question about what a pilcrow sign
is, but different cultures use the pilcrow sign for different purposes, and the
same applies to the section sign.
>
3. Should division signs in general be avoided? Or is the issue that there are
culture-specific division signs, and the division sign appropriate to a
particular culture should be used? (Given the international use of mathematics,
the US questions the assertion that "division signs are not used in
documents in several cultures.")
>
Proposed substitute text:
>
Information about culture-specific signs, and what should be avoided, may also
be included in Clause 13; for example the preferred abbreviation for
"number", the signs used to indicate a paragraph and a section in
text, and the preferred sign used to indicate division.
>
Rationale: Clarity.
Response:
accepted.
>
Clause 16: Personal name rules
>
FCD TECHNCIAL #62
>
CD2 TECHNICAL #123 protested the defective DoC on CD Objection #50. The
DoC on US CD2 TECHNICAL #123 was:
>
Not accepted. Issues like this can be addressed with TR 14652 technology.
>
The US reinstates its objection.
>
Rationale:
>
1. No evidence is presented that TR 14652 can be used to solve the questions
posed in CD1 OBJECTION #50. The Editor has justified his "Not
accepted" decision on CD2 TECHNICAL #123 with an unsupported assertion.
This is unacceptable.
>
2. The DoC on CD Objection #50 remains defective. The Editor failed to respond
to the questions raised by the US in this comment.
Response:
Noted.
>
FCD TECHNICAL #63
>
In CD2 TECHNICAL #124, the US recommended that this clause be annotated
"Not recommended".
>
DoC on CD2 TECHNICAL #124,
>
Not accepted. Issues like this can be addressed with TR 14652 technology.
>
Defective disposition. The US repeats its recommendation that this clause be
annotated "Not recommended".
>
Rationale: No evidence is presented that TR 14652 can be used to solve this
problem. The Editor has justified his "Not accepted" decision with an
unsupported assertion. This is unacceptable.
Response:
noted.
>
Clause 17: Inflection
>
FCD TECHNICAL #64
>
FCD text:
>
Languages vary much with respect to inflection, that is different forms of a
word depending of the context. In this clause the rules can be described or
referenced. Some common localization APIs today take some aspects of this into
account, for example the UNIX gettext() functions deal with singular/plural
forms of nouns.
>
In CD2 TECHNICAL #125, the US requested: 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.
>
DoC on CD2 TECHNICAL #125
>
Not accepted. Other software may have the ability to handle inflection.
>
Defective disposition. The US repeats its requirement to remove the sentence
beginning "Some common translation APIs..."
>
Rationale: No evidence is presented of software that has the ability to handle
inflection. The Editor has justified his "Not accepted" decision with
an unsupported speculation. This is unacceptable.
Response:
Accepted. The last sentence will be removed.
>
FCD TECHNICAL #65
>
In CD2 TECHNICAL #126, the US recommended 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.
>
DoC on CD2 TECHNICAL #126
>
Not accepted. Software is being produced to take account of this, for example
translation software.
>
The US repeats its recommendation that this clause be annotated "Not
recommended".
>
Rationale: No substantive evidence supporting the Editor's assertion about
translation software is presented. The disposition is defective.
Response:
noted.
>
Clause 22: Date and time
>
FCD TECHNICAL #66
>
In the FCD, the normative text of Clause 22 has been substantially modified:
>
This is for considerations in excess of clause 5, such as non-POSIX date
conventions, time zone names and daylight savings rules, week numbering,
national holidays, further date formatting rules in excess of the possibilities
of the POSIX standard, preferably also with a description of the field of use
for the format, such as in narrative text, in letters, in contracts, in formal
documents; and other ways that time may be expressed, like the British
"half seven", which means 07:30 or 19:30, where "halb
sieben" means 06:30 or 18:30 in Germany.
>
The normative text of Clause 22 in the CD2 (in clause 9.4) was identical to the
informative text in ISO/IEC 15897:1999 and CD1 of the revision (Clause 22: Date
and time in the informative Annexes F and G, respectively).
>
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 US objects to these unsubstantiated modifications (see FCD TECHNICAL #67
below), and continues to object to the inclusion of time zones and daylight
savings rules for the reasons given in CD1 OBJECTION #51 and CD2 TECHNICAL #128
and #130. There is a new problem with inclusion of the "half seven/halb
sieben" example in the normative FCD text (see FCD TECHNICAL #69 below).
>
The US proposes new text that resolves all these issues, while preserving the
examples:
>
Clause 22: Date and time
>
This clause is for date and time conventions which are not accommodated by
clause 5, that is, other ways in which time may be expressed beyond POSIX date
and time conventions. Such conventions should preferably be augmented by a
description of the field or fields where the convention is used.
>
NOTE 1: Date and time conventions that are not specified by POSIX include time
zone names, daylight savings rules, week numbering, national holidays, and
colloquial expressions. Examples of colloquial expressions are the British
"half seven," which means 07:30 or 19:30, and the German "halb
sieben" (literally, "half seven") which means 06:30 or 18:30.
>
NOTE 2: Fields of use include narrative text, letters, and legal documents such
as contracts.
>
Rationale: The statement of requirements (which is normative) must be separate
from specific cases and examples (which are informative). The specific cases
and examples in Clause 22 provide additional information intended to assist the
understanding or use of Clause 22. This conforms to the definition of
"supplementary elements" which are defined as informative (ISO/IEC
Directives, Part 2, clause 3.7.2). Therefore this information, which is part of
the text, must appear as notes or examples (ISO/IEC Directives, Part 2, clause
6.5.1).
>
Note: The literal translation of "halb sieben" has been added to make
the cultural differences in meaning apparent to a reader unfamiliar with
German.
Response:
accepted.
>
FCD TECHNICAL #67
>
Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote
>
In the FCD, the normative text of Clause 22 has been substantially modified :
>
This is for considerations in excess of clause 5, such as non-POSIX date
conventions, time zone names and daylight savings rules, week numbering,
national holidays, further date formatting rules in excess of the possibilities
of the POSIX standard, preferably also with a description of the field of use
for the format, such as in narrative text, in letters, in contracts, in formal
documents; and other ways that time may be expressed, like the British
"half seven", which means 07:30 or 19:30, where "halb
sieben" means 06:30 or 18:30 in Germany.
>
Remove the following text from FCD, Clause 22:
>
week numbering, national holidays, further date formatting rules in excess of
the possibilities of the POSIX standard, preferably also with a description of
the field of use for the format, such as in narrative text, in letters, in
contracts, in formal documents;
>
to yield:
>
This is for considerations in excess of clause 5, such as non-POSIX date
conventions, time zone names and daylight savings rules, and other ways that
time may be expressed, like the British "half seven", which means
07:30 or 19:30, where "halb sieben" means 06:30 or 18:30 in Germany.
>
Compare the resulting text with the corresponding normative text in CD2 (clause
9.4). This text in CD2 is identical to the informative text in Annex F of
ISO/IEC 15897:1999 and Annex G of CD1 15897.
>
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?
>
Rationale:
>
1. These substantive changes to normative text are not specified in any NB
comments on CD2, nor in the DoC on CD2 (WG 20 N1020). See Details below.
>
2. The overall scope of this clause;
>
for considerations in excess of clause 5, such as non-POSIX date conventions,
>
is unnecessarily repeated in the phrase:
>
further date formatting rules in excess of the possibilities of the POSIX
standard,
>
Details:
>
Comments on CD2 were made by Germany, Japan, Netherlands, UK, and USA.
>
Germany and the U.S. commented on CD2 clause 9.4 Contents of a Narrative
Cultural Specification. Japan, Netherlands, and UK did not comment on the
clause.
>
Germany's comments did not apply to Clause 22: Date and time. The US comments
on Clause 22 were: (a) a request to remove the entire clause (CD2 TECHNICAL
#128); (b) the defective discussion of "half seven"/"halb
sieben" (CD2 TECHNICAL #129), and (c) marking Clause 22 as
"controversial" if it was not removed (CD2 TECHNICAL #130).
>
US comments CD2 TECHNICAL #128 and #130 were not accepted in the Disposition of
Comments. The DoC on CD2 TECHNICAL #129 was:
>
Accepted. Changed to: Other ways that time can be expressed.
>
which sanctions the addition of "other ways that time may be
expressed".
Response:
Withdrawn by the US. This text was introduced in response to the Netherlands
CD2 comments.
>
FCD TECHNICAL #68
>
[CD1] OBJECTION #51
>
Section: Annex G, Clause 22 (Date and time)
>
CD1 text:
>
"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.
>
CD2 TECHNICAL #128
>
CD2 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.
>
In CD2 TECHNICAL #128, the U.S. still objected strongly to including time zone
information in cultural narratives (as stated in CD1 Objection #51), and
requested that the phrase "...time zone names and daylight savings
rules..." be removed. The US also objected:
>
Also, time zone information in a locale or cultural narrative was labeled [as]
controversial in TR 14652, and it is incorrect to elevate it to normative status
in this standard.
>
DoC on CD2 TECHNICAL #128
>
Not accepted. This spec is also in currently approved IS 15897,
>
so there is no new elevation. See also response to US comment 1.
>
and (on quoted CD1 OBJECTION #51)
>
Not accepted. It is a cultural convention what the timezone is called,
>
and it is not unfeasible to specify even the most complicated time zone
>
rules, eg for USA.
>
Then CD2 TECHNICAL #130 applies. See FCD TECHNICAL #70 below.
Response:
withdrawn by the US.
>
FCD TECHNICAL # 69
>
FCD text after application of FCD TECHNICAL #67 reads:
>
This is for considerations in excess of clause 5, such as non-POSIX date
conventions, time zone names and daylight savings rules, and other ways that
time may be expressed, like the British "half seven", which means
07:30 or 19:30, where "halb sieben" means 06:30 or 18:30 in Germany.
>
Examples do not belong in normative text. Delete the following two pieces of
text.
>
1. Delete this text: (including the trailing comma and space):
>
time zone names and daylight savings rules,
>
2. Delete this text (including the preceding comma and space):
>
, like the British "half seven", which means 07:30 or 19:30, where
"halb sieben" means 06:30 or 18:30 in Germany
>
Rationale: Notes and examples are informative elements (ISO/IEC Directives,
Part 2, clause 6.5.1).
>
Note: The US considers "non-POSIX date conventions" to be an
amplification of the definition in the preceding clause, and therefore
retention of this phrase in normative text is appropriate.
Response:
accepted in principle, as response to US comment 66 was accepted.
>
>
FCD TECHNICAL #70
>
Critical issue: Must be resolved to the satisfaction of the US to reverse vote
>
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.
>
DoC on CD2 TECHNICAL #130
>
Not accepted. The time zone names and daylight saving rules clause was already
present in the first edition of IS 15897. The clause is not not here breacause
of 14652 but reflects that timezone issues are a cultural issue.
>
The US request to remove "...time zone names and daylight savings
rules..." in CD2 TECHNICAL #128 was "Not accepted". The US
therefore strongly recommends that this clause be annotated
"Controversial". The US also recommends the addition of a note to
explain the annotation.
>
NOTE Clause 4.7 LC_TIME in ISO/IEC TR 14652 is labeled
"Controversial" for two reasons which are documented in clause D.2,
item 7 of ISO/IEC TR 14652.
>
Rationale: Defective DoCs.
>
The DoC on CD2 TECHNICAL #130 states:
>
The time zone names and daylight saving rules clause was already present in the
first edition of IS 15897.
>
DoC on CD2 TECHNICAL #128 states:
>
This spec is also in currently approved IS 15897, so there is no new elevation.
>
The relevant text in Annex F (informative) of International Standard ISO/IEC
15897:1999 is:
>
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
expression like "half seven" - what is then really meant - 06:30 as
in Germany or Denmark, or 07:30 as in Britain?
>
The important thing about this text is that it appears in informative annexes
in ISO/iEC 15897:1999 (Annex F) and CD1 15897 (Annex G). The comparable text in
CD2 (clause 9.4) and this FCD is normative, so there has been an elevation.
Because this text remains normative, it is essential that users be warned about
problems have been identified with respect to time zone information in a locale
or cultural narrative.
respronse:
accepted in principle. This text is now informative.
>
FCD TECHNICAL #71
>
Clauses 23, 26, 27, 28 and 30
>
In CD2 TECHNICAL #131 and #132, the US recommended that these clauses be
annotated "Not recommended" because the definitions are "too
vague to be useful", or "contain information that is
application-specific rather than culture-specific "
>
The DoC on these comments was:
>
Not accepted. There need not be any specific format for this, as it is
freeform.
>
The US reiterates its recommendation to annotate these clauses "Not
recommended".
>
Rationale: The DoCs are non-responsive. The US was not objecting to the format
for the information (it is freeform). The US was objecting to the fact that the
text of each of these clauses does a poor job of explaining what information
should be included when the clause is included in a Cultural Narrative
Specification.
Response:
not accepted, but note that this clause is now informative text.
>
Clause 12 Format of a Repertoiremap
>
FCD 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, defined with a line for each character 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. An escape
character can be used to escape the syntactical meaning of the following
character, so that the following character is included literally. The default
escape character for the Repertoiremap is the reverse solidus (\). The escape
character for the Repertoiremap 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.
>
>
FCD TECHNICAL #72
>
>From the DoC on US CD2 TECHNICAL OBJECTION #44
>
(b) For the POSIX 1993 spec, this will still be referenced in the standard,
>
and thus references can be retained.
>
Delete the sentence:
>
It is recommended to use, whenever possible, character names specified in
ISO/IEC 9945-2:1993 Annex G.
>
Rationale:
>
1. International Standard ISO/IEC 9945 has been revised and most of the
character names in Annex G of ISO/IEC 9945-2:1993 have been eliminated.
>
2. ISO/IEC 9945-2:1993 is obsolete and no longer available from ISO. It is
ridiculous to recommend use of a document that is both obsolete and
unavailable.
Response:
accpeted in principle. Moved to a note, worded as follows:
"Chraracter
names as specified in ISO/IEC 9945-2:1993 annnex G may be used,
many
of the charmap registrations do so."
>
FCD TECHNICAL #73
>
>From the DoC on US CD2 TECHNICAL OBJECTION #44
>
(c) The definition here of the escape character is for the specific
>
15897 repertoiremap format, (and not the charmap format). If there is no
>
specification for redefining the escape character, this is not possible
>
according to this spec, so these wordings are needed.
>
>
Delete these sentences:
>
The default escape character for the Repertoiremap is the reverse solidus (\).
The escape character for the Repertoiremap 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.
>
Rationale:
>
1. This is the wrong place for this information. The specification for how to
redefine the escape sequence does not belong in this procedural standard but in
the technical standard that specifies a particular repertoiremap syntax.
>
2. There is more than one convention for redefining the escape sequence for a
repertoiremap. It is wrong to describe only one (especially when there was no
consensus on its technical suitability).
Response:
not accepted. However, "The repertoiremap" will be changed to
"a
Repertoiremap", 3 times.
>
FCD TECHNICAL #74
>
Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote
>
4th and 5th sentences:
>
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.
>
Although the changes made to these sentences were not requested in NSB comments
or WG2 decisions, the substitution of "shall be" for "are"
[separated] and "should be" [preceded] is correct.
>
Change:
>
are each surrounded by
>
to
>
shall each be surrounded by
>
Rationale: Consistency.
Response:
accepted.
>
Clause 13 Rules for Cultural Specifications
>
>
Clause 13.2.2
>
13.2.2 Format of a POSIX Locale or Charmap
>
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.
>
>
FCD TECHNICAL #75
>
Critical issue: Must be resolved to the satisfaction of the US to reverse vote
>
Item (b) in US comment CD2 TECHNICAL #35 on the two lasts paragraph of CD2
clause 9.3.2, stated:
>
The US objects to the technique specified in Annex E; it must not be part of
this standard (see CD2 TECHNICAL OBJECTION #37).
>
The DoC on US comment CD2 TECHNICAL #35 was:
>
Partly accepted. The repertoiremap is an integral part of this
>
standard, and needed and already present in the 1st edition,
>
so it cannot be removed. The posix locale and charmap specs
>
will be updated.
>
Delete the comma and this text:
>
or for POSIX Locales the technique specified in Annex E
>
Rationale: Annex E is normative. It is adding normative capabilities to POSIX
without the knowledge or consent of the authors of ISO/IEC 9945 or the National
Bodies active in WG15.
>
See also FCD TECHNICAL comments on Annexes E and F below.
Response:
accpted in principle. The text is reworded as follows:
Locales
which are otherwise conformant to ISO/IEC 9945,
but
which make use of the extention technique defined in annex E,
are
also permissable for registration.
>
Clause 13.2.3
>
FCD TECHNICAL #76
>
FCD, clause13.2.3 Format of a Repertoiremap
>
If a Repertoiremap is included in a registration, it shall follow the format
described in
>
clause 12.
>
CD2, clause 9.3.2, last paragraph:
>
The format of the Repertoiremap shall be conformant to clause 9.3.9.
>
Item (c) in US comment CD2 TECHNICAL #35 on CD2 clause 9.3.2 stated:
>
As noted before, the TR 14652 Repertoiremap is controversial and shall not be a
normative part of this standard.
>
The DoC on US comment CD2 TECHNICAL #35 was:
>
Partly accepted. The repertoiremap is an integral part of this
>
standard, and needed and already present in the 1st edition,
>
so it cannot be removed. The posix locale and charmap specs
>
will be updated.
>
It is unclear which standard is being referred to in the DoC. If "this
standard" refers to ISO/IEC 15897, the text addressing the format for a
repertoiremap has not been proposed for removal. FCD clause 12 is almost
identical to clause 6.9 if the first edition (1999),. The US was objecting to
the repertoiremap in TR 14652. TR 14652 is not a standard, and was not
published until 2001 (i.e., after the first edition of ISO/IEC 15897).
>
The US has no objection to the rewording of clause 13.2.3
Response:
noted
>
Clause 13.4
>
FCD TECHNICAL #77
>
Clause 13.4, first sentence:
>
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.
>
Delete "(ISO 2375 registration number 6)".
>
Rationale: The 1991 edition of ISO/IEC 646 is cited in clause 2 Normative
references. Furthermore:
>
(a) There is no explicit registration for the 1991 version of ISO/IEC 646 in
the ISO/IEC 2375 Registry.
>
(b) ISO-IR 6 designates ISO 646, USA Version X3.4 - 1968.
>
Citing the registration number is potentially confusing to users who are
unaware of the relationship between US ASCII and the IRV of ISO/IEC 646.
Response:
accepted
>
Clause 13.4, second sentence
>
FCD TECHNICAL #78
>
Clause 13.4, second sentence:
>
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.
>
US CD2 TECHNICAL OBJECTION #37 requested removal of this sentence. The DoC on
US CD2 TECHNICAL OBJECTION #37 was:
>
Not accepted. Non-invariant ASCII characters is still a problem, even in
>
2003, in everyday places in a number of places, including Denmark and Korea.
>
Delete this sentence (for the following new reason):
>
This sentence conflicts with the specification in the preceding sentence for
use of "ISO/IEC 646 International Reference Version".
>
1. In the IRV of ISO/IEC 646, the options for the non-invariant characters have
been exercised (ECMA-006, clause 1.2). Thus, the IRV has a completely invariant
content, and the non-invariant characters do not present a problem.
>
Reference:
http://www.ecma-international.org/publications/standards/ECMA-006.HTM
>
2. There seems to be confusion between the occurrence of non-invariant ASCII
characters in very old legacy data (which causes difficulties in their correct
interpretation) and what is being specified here: use of a particular character
set to specify rules for the documentation of cultural elements. Roman Czyborra
(see Background information below) says that national variants of ASCII fell
out of use because ISO/IEC 8859-1 provided a more interoperable standard.
>
The US also notes that both the 1993 and 2003 versions of the POSIX standards
allow all graphic characters in ISO 646 IRV. Given the need of POSIX
implementers for registered cultural conventions, it would be a major
disservice to the POSIX community if ISO/IEC 15897 disallowed some of the
characters that are valid for POSIX.
>
>
Background information:
>
ASCII and its national variants were declared international standard ISO 646 in
1972. Back then, the socialist countries managed to substitute the
international currency sign € for ASCII's capitalist dollar sign $ in the first
international reference version ISO-646-IRV but this was revised in 1991 and
now ISO-646-IRV is a synonym for ISO-646-US or US-ASCII as it is used in the
core Internet protocols. ISO-646's national variants have fallen out of use
because of their obvious problems and because the 8bit ASCII extension
ISO-8859-1 has offered a more interoperable standard.
>
Source: Czyborra, Roman. Good ole' ASCII.
http://czyborra.com/charsets/iso646.html
Response:
not accepted. WG20 could not reach consensus to make the proposed change.
>
FCD TECHNICAL #79
>
Critical issue: Must be resolved to the satisfaction of the US to reverse vote
>
Clause 13.4, last sentence:
>
If characters outside ISO/IEC 646 International Reference Version are needed,
character names defined in a ISO/IEC 15897 Repertoiremap shall be used.
>
Delete
>
an ISO/IEC 15897 Repertoiremap
>
and substitute:
>
a repertoiremap formatted
according to clause 12.
>
Rationale:
>
1. This FCD does not include a specification for a repertoiremap. Clause 12 merely
defines the format of a repertoiremap. ISO/IEC 15897 is a procedural standard;
the specification of a repertoiremap must come from a technical standard.
>
2. See also US comments on Foreword and Introduction.
Response:
accepted.
>
Clause 13.7, third paragraph
>
FCD text:
>
For Types 3, 4, and 6, POSIX Charmaps, POSIX Repertoiremaps, and
Machine-parsable coded character set specifications:
>
10. Suggested Charmap or ISO/IEC 15897 Repertoiremap or other name
>
>
FCD TECHNICAL #80
>
Critical issue: Must be resolved to the satisfaction of the US to reverse vote
>
Delete the second occurrence of "POSIX" so that the text reads:
>
For Types 3, 4, and 6, POSIX Charmaps, Repertoiremaps, and Machine-parsable
coded character set specifications:
>
Rationale: POSIX does not and never has defined repertoiremaps.
>
Note: POSIX is defined solely by the normative references to the four parts of
International Standard ISO/IEC 9945.in clause 2 of the FCD.
response:
accepted
>
FCD TECHNICAL #81
>
Critical issue: Must be resolved to the satisfaction of the US to reverse vote
>
In CD2 TECHNICAL #40, the US requested addition of:
>
A TR 14652 Repertoiremap shall not be used.
>
The DoC on this US comment was:
>
Partially accepted. See response to US comment 1. The reference for
repertoiremaps will be clarified to mean the 15897 repertoiremap.
>
Delete
>
"ISO/IEC 15897"
>
Rationale:
>
1. This clause describes the content of the application form. The wording on
the application form (see Annex A) is:
>
10. Charmap, Repertoiremap or Machine-parsable coded character set name:
>
2. This FCD does not include a specification for a repertoiremap. Clause 12
merely defines the format of a repertoiremap. ISO/IEC 15897 is a procedural
standard; the specification of a repertoiremap must come from a technical
standard.
>
3. See also US comments on Foreword and Introduction.
Response:
accepted
>
Clause 14 Specification of the token identifier
>
>
FCD TECHNICAL #82
>
Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote
>
Clause 14, first paragraph
>
The last sentence reads:
>
The maximum lenght of a token identifier is 200 characters.
>
This sentence does not appear in the CD2. It has not been sanctioned by an NSB
comment nor by WG20 consensus. It must be removed.
Response:
Withdrawn by the US, because it was an error. The text was introduced as a
response
to CD2 US comment 19.
>
Clause 14, third and sixth paragraphs
>
FCD TECHNICAL #83
>
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?
>
DoC on CD2 TECHNICAL #43:
>
Accepted. National Body is intended.
>
Correction has only been made to 3rd paragraph. In 6th paragraph (immediately
above NOTE 2), change "National Standardization Organizations" to
"National Bodies".
Response:
accepted
>
Clauses 15 and 16
>
Was New clauses on Registration procedures
>
>
FCD TECHNICAL #84
>
>From CD2 TECHNICAL #49
>
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.
>
DoC on US CD2 TECHNICAL #49
>
Accepted, as noted in US comment 50 and 51.
>
Conflict between this DoC and the disposition of US comment #50 which was
"Accepted in principle".
Response:
noted.
>
Clause 15 Initial registration procedures
>
>
DoC on US CD2 TECHNICAL #50
>
Accepted in princple. What is technical will be clarified as only
>
technical requirements needed for registration, such as conforming to syntax
>
and administrative issues.
>
>
>
Clause 15.2
>
Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote
>
FCD TECHNICAL #85
>
The Sponsoring Authority shall submit an application and associated proposed
token identifiers for registration of a cultural specification to the
Registration Authority.
>
Unsubstantiated changes to US text which was Accepted:
>
"an application for registration" --> "an application and
associated proposed token identifiers for registration"
>
Delete "and associated proposed token identifiers".
>
Rationale: Proposed token identifiers are just one component of an application.
There is no need to note them separately here.
Response:
accepted
>
>
Clause 15.3
>
FCD TECHNICAL #86
>
First item:
>
The applicant is a Sponsoring Authority as identified in clause 7. The RA shall
reject applications for registrations which come from sources other than the
Sponsoring Authorities as defined in clause 7, or applications for
registrations that the Sponsoring Authority does not have to authority to
submit according to clause 7.1 or clause 7.2 item e. The Registration Authority
may refer the applicant to an appropriate Sponsoring Authority if one can be
identified.
>
Changes to US text:
>
, or applications for registrations that the Sponsoring Authority does not have
to authority to submit according to clause 7.1 or clause 7.2 item e.
>
Delete
>
or clause 7.2 item e
>
Rationale: Clause 7.2 item e describes the components of an application for
registration. Therefore, it belongs in clause 15.4. It does not have to do with
whether an applicant may submit an application , i.e., is recognized as a
legitimate Sponsoring Authority.
Response:
accepted.
>
FCD TECHNICAL #87
>
Second item:
>
The proposed cultural specification is not identical to one already registered.
>
Omitted (justifiably) by the Editor. Text should have been "is
identical". Add correctly worded item in the position shown in CD2
TECHNICAL #50:
>
-- The proposed cultural specification is identical to one already registered.
Response:
accepted in principle. Text added:
"The
proposed cultural specification is not identical to one already
registered."
The
following paragraph will be changed from "this requirement" to
"either of these
requirements".
>
>
Clause 15.4
>
FCD TECHNICAL #88
>
Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote
>
- The application for registration is in the proper syntax of the type of the
Cultural specification, See clause 13.2, 13.3, 13.4 and 13,5.
>
Not part of US text.
Response:
accepted in principle.
The
change was done as a consequence of the CD2 response to US comment 50.
13,5
will be deleted.
Clause
changed to clauses.
A
new paragraph will be added with the following words:
The
format of the application conforms to clause 13.5.
>
Clause 15.5
>
FCD TECHNICAL #89
>
Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote
>
FCD, clause 15.5, first sentence:
>
The Registration Authority shall submit the application to the RA-JAC for
review for syntactical and administrative requirements required for the
registration.
>
Changes to US text:
>
"for the technical review" --> "for review for syntactical
and administrative requirements required for the registration".
>
>
Change back to original text.
>
Rationale:
>
1. The RA-JAC is not responsible for ensuring that an application for
registration meets the administrative requirements.
>
2. The Editor has provided no explanation of why "technical" should
be replaced by "syntactical", and whether there is a difference
between the two terms.
The
Response: partially accepted. The text "and administrative" will be
deleted.
The
editors explanation for the use of the word "syntactical" was
accptable to the US.
>
FCD TECHNICAL #90
>
Delete the four items in clause 15.5 (which duplicate those in clause 15.4) and
substitute these two items:
>
- 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>.
Response:
Accepted. The text will be changed with substitution of
"technical"
to "syntactical" and the clause number will be 13.7.
>
Clause 15.6
>
FCD TECHNICAL #91
>
Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote
>
The RA-JAC shall report the results of its evaluation for formal registration
requirements within 30 days to the Registration Authority and shall describe
any formal concerns with the proposed registration.
>
Changes to US text:
>
"evaluation" --> "evaluation for formal registration
requirements:
>
no time specified --> "within 30 days"
>
"technical concerns" --> "formal concerns"
Response:
Withdrawn by the US.
The
editors explanation for the change was accptable to the US.
>
Clause 15.7
>
FCD TECHNICAL #92
>
Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote
>
The Registration Authority shall inform the Sponsoring Authority of any changes
needed to satisfy the concerns on formal registration requirements of the
RA-JAC.
>
Changes to US text::
>
"concerns" --> "concerns on formal registration
requirements"
>
Delete "on formal registration requirements".
>
Rationale: It would be necessary to define the "formal registration
requirements".
>
Response:
accepted in principle. "formal" will be deleted here and in 15.6.
15.7
will be reworded to: " concerns of the RA-JAC regarding registration
requirements."
>
Clause 15.8
>
After an application for registration has passed its review for formal errors
by the Registration Authority and by the RA-JAC, the Registration Authority
shall circulate the application with the proposed token identifiers to the
members and liaison organizations of the subcommittee responsible for
maintaining this standard and to the RA-JAC for a three-month information and
comment period.
>
Changes to US text::
>
"its review" --> "its review for formal errors"
>
"the application" ==> "the application with the proposed
token identifiers"
>
"standard" --> "standard and to the RA-JAC"
>
>
FCD TECHNICAL #93
>
Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote
>
Delete "for formal errors"
>
Rationale:
>
1. Redundant. The items being reviewed are defined in detail in preceding
clauses.
>
2. Would require the definition of what constitutes a "formal error".
>
Response:
accepted in principle. "formal" changed to "syntactical and
administrative".
>
FCD TECHNICAL #94
>
Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote
>
Delete "with the proposed token identifiers".
>
Rationale: Confusing. The wording "application with the proposed token
identifiers" suggests that there is an application without the proposed
token identifiers that is not circulated to members and liaison organizations.
Response:
accepted in principle. Change "with" to "and".
>
FCD TECHNICAL #95
>
Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote
>
Delete "and to the RA-JAC".
>
Rationale: The RA-JAC has just seen the application. It does not need to see it
again.
Response:
Withdrawn by the US.
>
>
FCD TECHNICAL #96
>
shall circulate the application to the members and liaison organizations
>
Why should the applications for registration be circulated to the liaison
organizations when they are unable to act as a Sponsoring Authority? (See FCD
TECHNICAL #26)
Response:
withdrawn by US.
>
Clauses 15.9 and 15.10
>
FCD TECHNICAL #97
>
Text proposed by the US in CD2 TECHNICAL 50:
>
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.
>
FCD text:
>
15.9 The Registration Authority shall forward all comments received according
to clause 15.8 to the Sponsoring Authority for possible integration in the
final registration by the Sponsoring Authority.
>
15.10 If the Sponsoring Authority revises the application, the Registration
Authority shall ascertain that the revised application complies to the
syntactical and administrative requirements listed in clause 15.4.
>
CD2 TECHNCIAL #114 and #115 addressed the same issue in items e and f in clause
7.4 (now transferred to clause 15).
>
DoC on CD2 TECHNICAL #114 stated:
>
No change. The intent is that the SA is the authority over its application,
>
and that nothing can be registered against the will of the SA.
>
DoC on CD2 TECHNICAL #115 stated:
>
Partially accepted. Wording will be changed, but the RA will have no say
>
about whether the changes are acceptable.
>
The question here is: who is responsible for resolving review comments made by
P-members about an application for registration? ISO operates by consensus. All
parties must be involved in deciding whether a comment is justified.
>
1. The Registration Authority must review the comments The Registration
Authority will reject any comments that it considers in error. The Registration
Authority may consult with the RA-JAC about questionable comments.
>
2. Any comments that would prevent registration must be forwarded to the
Sponsoring Authority for action. The Sponsoring Authority will either explain
why the comment is wrong (registration can proceed) or will submit a
replacement application if the comment is justified.
>
Replace clauses 15.9 and 15.10 with the following clauses:
>
15.9 The Registration Authority shall consider all comments received from the
subcommittee review (clause 15.8). The Registration Authority may request the
RA-JAC to provide expert technical advice on comments.
>
15.10 The Registration Authority shall forward any comments that prevent
approval of the application for registration to the Sponsoring Authority for a
response.
>
15.10.1 If the review comment is in error, the Sponsoring Authority shall
submit an explanation of why it is in error to the Registration Authority.
>
15.10.2 If the review comment is justified, the Sponsoring Authority shall
either request withdrawal of the application (see clause 20.1) or submit a
corrected application, A corrected application shall be subjected to the
procedures specified in clauses 15 and 16 as though it was a new application.
>
Rationale:
>
1. The new clauses describe the consensus procedure.
>
2. FCD clause 15.10 is inadequate. An application for registration is subjected
to review by both the Registration Authority (clauses 15.3 and 15.4) and by the
RA-JAC (clause 15.5). A replacement application should be subjected to the same
procedure.
Response:
Accepted in principle. The wordings of 15.9 and 15.10 is replaced as follows:
(1)
Replace current 15.9 with the wording of the proposed 15.10:
15.9
The Registration Authority shall forward any comments that prevent approval of
the application for registration to the Sponsoring Authority for a response.
(2)
Replace current 15.10 with the merged wording from the proposed 15.10.1 and
15.10.2:
15.10
If the review comment is in error, the Sponsoring Authority shall submit an
explanation of why it is in error to the Registration Authority. If the review
comment is justified, the Sponsoring Authority shall either request withdrawal
of the application (see clause 20.1) or submit a corrected application, A
corrected application shall be subjected to the procedures specified in clauses
15 and 16 as though it was a new application.
>
Clause 15.13
>
FCD TECHNICAL #98
>
The Registration Authority shall request the RA-JAC to provide expert advice on
technical comments. The Registration Authority may attach comments from the
RA-JAC as described in clause 9.3 item e with the final registration.
>
Modification of part of US clause x.9. Modifications are editorial in nature.
Response:
noted. No change necessary.
>
Clause 16 Processing of an approved application
>
>
Initial sentence:
>
FCD TECHNICAL #99
>
Following completion of approval of an application for registration, the
Registration Authority shall:
>
Delete this sentence.
>
Rationale: This is a hanging paragraph which "should be avoided since
reference to them is ambiguous." (ISO/IEC Directives, Part 2, clause
5.2.4)
Response:
accepted in principle. However, the sentence will be completed with: "the
actions
listed
in this clause".
>
Clause 16.1
>
FCD TECHNICAL #100
>
The US notes the addition of "numeric" identifiers to make the
distinction from alphanumeric token identifiers.
Response:
noted.
>
17.1 Appeals against rejection
>
>
Initial sentence:
>
FCD TECHNICAL #101
>
Appeal against the decision of the Registration Authority can be made as
follows:
>
Delete this sentence.
>
Rationale: This is a hanging paragraph which "should be avoided since
reference to them is ambiguous." (ISO/IEC Directives, Part 2, clause
5.2.4)
Response:
accected in principle. The sentence is reworded with:
shall
be made according to the procedures in this clause.
>
Clause 17.1
>
FCD TECHNICAL #102
>
Unsubstantiated change: Must be resolved to the satisfaction of the US to
reverse vote
>
FCD text:
>
If the Registration Authority rejects an application, the Sponsoring Authority
may appeal that rejection based only on whether the application meets the
syntactical or administrative requirements for a registration as described in
clause 13.
>
Change by Editor to Accepted US text:
>
"technical or
administrative" --> "syntactical or administrative"
>
Change back to original text.
>
Rationale: The Editor has provided no explanation of why "technical"
should be replaced by "syntactical", and whether there is a
difference between the two terms.
Response:
Withdrawn by the US. See response to US comment 89.
>
New clause (numbered 17.2) Appeals against registration
>
>
FCD TECHNICAL #103
>
Critical issue: Must be resolved to the satisfaction of the US to reverse vote
>
This new clause parallels clause 15.1 Appeals against registration in ISO/IEC
2375:2003.
>
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>
>
DoC on CD2 N1020
>
Not accepted. NBs can comment on the application, but the SA will have the
final
>
word.
>
This clause is necessary. All corrections to an application or to an existing
registration should be supplied by the Sponsoring Authority, but the Sponsoring
Authority should NOT have the "final word". This clause is intended
to prevent erroneous information from being included in the Registry.
>
In addition, this member body right WAS specified in N 849, the CD 15897.
Clause 7.2 states:
>
A Member Body of the JTC 1 subcommittee responsible for the maintaining of this
International Standard may object to a forthcoming publication of a
registration by the Registration Authority, but solely on the ground that the
requirements in Clause 6 are not met.
>
The normative text of this clause was eliminated from CD2 15897 (N 987) without
authorization to do so via a NB comment (see DoC on CD 15897, N 957).
>
To restore this member body right:
>
1) Renumber clauses 17.2 through 17.4 as 17.3 through 17.5.
>
2) Insert clause 17.2 Appeals against registration with the following text and
numbering:
>
<begin text>
>
17.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.
>
17.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 clause
15.
>
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>
>
Rationale:
>
ISO operates by consensus. All parties must be involved in deciding whether
something is correct.
>
With regard to item 3, there is no harm in questioning the correctness of
supplied cultural information. The Sponsoring Authority would be responsible
for determining whether there is an error, and correcting the application if
that proves to be the case.
>
Note: Rationale applies also to 17.4 Resolution of an appeal.
Response:
Accepted in principle. The text proposed by the US will be used with
the
following changes: "technical" is changed to "syntactical"
and
Item
3) will be deleted.
>
17.4 Resolution of an appeal
>
>
FCD TECHNICAL #104
>
Critical issue: Must be resolved to the satisfaction of the US to reverse vote
>
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>
>
DoC on CD2 TECHNICAL #55
>
Not accepted. See response to US comment 53.
>
Text of response to US comment #53:
>
Not accepted. NBs can comment on the application, but the SA will have the
final
>
word.
>
This clause is necessary. All corrections to an application or to an existing
registration should be supplied by the Sponsoring Authority, but the Sponsoring
Authority should NOT have the "final word". This clause is intended
to prevent erroneous information from being included in the Registry.
>
As noted above in the technical comment on proposed clause 17.2, the normative
text of clause 7.2 of CD 15897 was not carried over to CD2 15897 (N 987)
although there was no NB comment requesting removal of this text (see DoC on CD
15897, N 957).
>
To remedy this improper action:
>
1) Renumber clause 17.4.3 as 17.4.4.
>
2) Insert the following text as clause 17.4.3 with the heading Appeals against
registration:
>
<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 17.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>
Response:
Accepted in principle. The text and renumbering proposed
by
the
"the
appeal" changed to "an appeal against registration".
"technically"
is changed to "syntactically" and ", Item 3)" will be
deleted.
Delete
from "If the appeal.." to end of text.
In
17.4.2 change "the appeal" to "an appeal against
registration" and "technically" to "syntactically".
>
FCD clause 17.4.3
>
If four-fifths of the members of the RA-JAC cannot agree on how to resolve an
appeal, then the appeal shall be submitted by the Registration Authority within
90 days after the receipt of an appeal to the P-members of the JTC 1
subcommittee responsible for the maintaining of this International Standard, to
decide according to its voting procedures.
>
CD2 TECHNICAL #56 requested two changes to CD2 clause 10.4.3:
>
>
FCD TECHNICAL #105
>
Critical issue (ISO procedures): Must be met to satisfy the US and to reverse
vote
>
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.)
>
DoC on CD2 TECHNICAL #56
>
Not accepted. SC22 may have additional procedures beyond the JTC 1 procedures.
>
This is an unjustified and unsubstantiated rejection. The rationale describes
SC22 procedures.
Response:
accpeted.
>
FCD TECHNICAL #106
>
Critical issue (ISO procedures): Must be met to satisfy the US and to reverse
vote
>
CD2 TECHNICAL #56 (part):
>
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.
>
DoC on CD2 TECHNICAL #56
>
Not accepted. SC22 may have additional procedures beyond the JTC 1 procedures.
>
This is an unjustified rejection.
>
The Editor is attempting to justify his improper rejection by describing an
imaginary situation. SC22 does not have any additional procedures.
>
SC22 is subordinate to JTC1, so it operates according to the Procedures for the
technical work of ISO/IEC JTC 1 (i.e., the JTC 1 Directives). In the unlikely
event that SC22 devised some additional procedures, this standard could be
revised AT THAT TIME to specify use of the new procedures.
>
Note: The JTC 1 Directives are referenced in clause 13.1.
>
or one of the approved document formats of ISO/IEC JTC 1, as noted in the JTC 1
directives, Annex H.4.
Response:
accepted.
>
Clause: 18 Revisions
>
>
FCD TECHNICAL #107
>
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.
>
When a new registration application is based on an existing registration,
either by the same Sponsoring Authority, or another Sponsoring Authority, then
the Registration Authority shall create a new registration. The Registration
Authority shall also add cross-reference notes to the two registrations.
>
Number the two paragraphs as clause 18.1 and 18.2 respectively.
>
Rationale: ISO/IEC Directives, Part 2, Clause 5.2.4.
Response:
accepted.
>
19 Addition of token identifiers to an existing registration
>
>
FCD TECHNICAL #108
>
CD2 TECHNICAL #66 requested:
>
Add a new clause with the title:
>
Additions to an existing registration
>
Proposed heading was Accepted, but the Editor made this change:
>
Additions --> Addition of
token identifiers
>
The US has no objection since the text deals with the addition of token
identifiers.
>
Text is as supplied except that "new" was added before
"application".
Response:
noted.
>
FCD TECHNICAL #109
>
CD2 TECHNICAL #66 also requested:
>
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.
>
Text has not been supplied.
Response:
noted. See also respose to US comment 116.
>
Clause: 20 Withdrawal
>
>
Initial paragraphs:
>
FCD TECHNICAL #110
>
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 of an existing registration that it has sponsored. Parts
may be withdrawn only by withdrawing the whole registration, and then registering
the parts in question according to the rules defined in this International
Standard.
>
A declaration of withdrawal may, but need not, be accompanied by a statement of
the reasons for the withdrawal.
>
Clause number omitted. Text modified with addition of rules about parts.
Response:
accepted. clause numbers will be added.
>
FCD TECHNICAL #111
>
Move the following text to a new clause (see below):
>
Parts may be withdrawn only by withdrawing the whole registration, and then
registering the parts in question according to the rules defined in this
International Standard.
>
and substitute a reference:
>
Procedures on withdrawal of parts of a registration or application are
specified in clause 20.3.
Response:
Accepted.
>
Clause 20.1
>
FCD TECHNICAL #112
>
When the Registration Authority is notified, it shall take no further action to
process the application.
>
If the application for registration is being circulated for comment according
to clause 15.8, the Registration Authority shall notify the members of the
subcommittee that the application has been withdrawn by the Sponsoring
Authority.
>
Number these clauses as 20.1.1 and 20.1.2.
>
Rationale: ISO/IEC Directives, Part 2, clause 5.2.
Response:
accepted
>
Clause 20.2
>
FCD TECHNICAL #113
>
After withdrawal, the registration shall remain in the register and continue to
be identified by the allocated numeric identifier and token identifiers.
>
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.
>
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.
>
The Registration Authority shall inform the subcommittee responsible for
maintaining this standard of the withdrawal of a registration.
>
First paragraph:
>
The US notes that "and token identifiers" was added.
Response:
noted.
>
FCD TECHNICAL #114
>
Delete the second paragraph of clause 20.2.
>
Rationale: Duplicates next paragraph, except for "was withdrawn"
rather than "has been withdrawn". "was withdrawn" is
preferable.
Response:
accepted.
>
>
FCD TECHNICAL #115
>
Number these clauses as 20.2.1, 20.2.2, 20.2.3.
>
Rationale: ISO/IEC Directives, Part 2, clause 5.2.
Response:
accepted.
>
New clause [ 20.3 proposed] Procedures for parts
>
>
FCD TECHNICAL #116
>
Add a new clause with title "Procedures for parts"
>
Add a new subclause numbered 20.3.1 with title "Parts of an existing
registration" and the following text:
>
Part of an existing registration cannot be withdrawn or modified. To change a
part (either to add a part, modify an existing part, or withdraw a part), the
whole registration must be withdrawn, and a revision submitted as a new
application for registration.
>
Add a new subclause numbered 20.3.2 with title "Parts of an existing
application" and the following text:
>
Part of an existing application cannot be withdrawn or modified. To change a
part (either to add a part, modify a part, or withdraw a part), the whole
application must be withdrawn, and resubmitted after revision.
>
Rationale: Separates rules for existing registration and unapproved
application. Clarifies what constitutes a change to a part.
Response:
accepted.
>
FCD TECHNICAL #117
>
Add a reference to this clause 20 from clause 4.5 No modification nor deletion
of registrations, worded as follows:
>
Withdrawal of part of an existing registration is prohibited by clause 20.3.1.
>
Rationale: Pointer from definition to procedures for complying with the
definition.
Response:
acepted.
>
Annex C External References to Cultural Specifications
>
>
C.4 Transfer Syntax
>
FCD TECHNICAL #118
>
CD2 TECHNICAL OBJECTION #70 proposed changing 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.
>
DoC on CD2 TECHNICAL OBJECTION #70
>
Not accepted. Other character encodings than UTF-8 needs to be supported.
>
Change the text as follows:
>
When transferring the contents of a registry entry over a network, the UTF-8
form of ISO/IEC 10646 shall be preferred for data encoding. Alternatively,
transfer syntaxes as defined in ISO/IEC 2022 may be used.
>
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 preferred when transferring
the contents of an entry over the network.
Response:
accepted.
>
Annex D Example Narrative Cultural Specifications
>
>
FCD TECHNICAL #119
>
The title of the Annex does not match the title specified in the DoC (N1020):
>
Accepted. The title will be "Sample narrative cutltural
specifiaction"
>
and some interoductory text that this just an example and not something that
>
is in the registry.
>
Furthermore, the final "s" in "Specifications" is smaller
than the rest of the word. it is unclear whether the word is intended to be
singular or plural.
>
The US proposes that the FCD title be retained, but modified slightly by the
addition of "of a" and changing "Specifications" to
"Specification" so that it reads:
>
Example of a Narrative Cultural Specification
>
Rationale: Better style.
Response:
accepted.
>
>
FCD TECHNICAL #120
>
General comments on CD2 Annex D
>
2. Defective or outdated information (CD2 TECHNICAL #72)
>
3. Concerns about status of examples (CD2 TECHNICAL #73)
>
The DoC on CD2 TECHNICAL #72 stated:
>
Not accepted. We should respect the information from the national
>
bodies that provided this text. Text may be outdated as the standard
>
ages, so it is natural that some information is out of date.
>
The US is still concerned about the existence of obsolete information in
examples, but recognizes that the Danish NB is responsible for the content of
this Annex .
Response:
noted.
>
FCD TECHNICAL #121
>
The CD2 DoC on US Comments on CD2, Annex D, Sample Narrative Cultural
Specification for Danish and Irish (Appendix 3 of WG 20 document N1010)
included the following:
>
All of the comments in this appendix are not accepted. These comments will be
relayed to the Danish member body for possible changes.
>
Has this been done? If it has been done, has there been a response from Dansk
Standard? If it has not been done, why not?
Respnse:
The Danish NB has been contacted, and will review the draft FDIS text,
and
may suggest further corrections to the contents of Annex D.
>
FCD TECHNICAL #122
>
The US notes that although the DoC on CD2 TECHNICAL #72 stated:
>
... We should respect the information from the national bodies that provided
this text. ...
>
and the DoC on Appendix 3 of WG 20 document N1010 stated:
>
All of the comments in this appendix are not accepted. These comments will be
relayed to the Danish member body for possible changes.
>
changes have been made to Clause 11 and Clause 22 of Annex D without any
documented input from Dansk Standard.
Response:
Noted.
>
FCD TECHNICAL #123
>
The date of the example in Annex D is 2002-10-08
>
Source: Dansk Standard, date: 2002-10-08, version: 2.5
>
but the text of FCD clause 22 mentions "2003":
>
The timezone is UTC+0100 in the winter, UTC+0200 in the summer. The daylight
savings period currently (2003) changes by one hour the last Sunday in March at
02:00, and back again by one hour the last Sunday in October at 03:00. This may
change in the future. There is no official names for the timezones.
>
The CD2 text has "1995".
>
Why is there a difference between the publication date of the Narrative
Cultural Specification used as the example and dated information in it?
Response:
noted, refer to US comment 121.
>
Clause 15
>
FCD TECHNICAL #124
>
The FCD text of Clause 15 in the example of a Narrative Cultural Specification
reads:
>
A proposed general input method is included in DS/ISO/IEC 9945-1 annex F.
>
This is a reference to the 1991 edition of ISO/IEC 9945-1, which was adopted as
a Danish national standard designated DS/ISO/IEC 9945-1:1991.
>
Problems with this clause that should be communicated to Dansk Standard:
>
1. The reference to "annex F" should be changed to "Annex
E". There is no Annex F in ISO/IEC 9945-1, and so not in DS/ ISO/IEC
9945-1 either.
>
2. The reference is obsolete. DS/ISO/IEC 9945-1:1991 was withdrawn by Dansk
Standard on 1997-09-24.
>
Source: Result of search for Document ID "9945" on Dansk Standard Web
site http://www.en.ds.dk/ The same search on http://www.ds.dk/ (in Danish)
returns the same result.
>
Note: Even ISO/IEC 15897:1999 refers to a standard that had already been
withdrawn when the first version of this International Standard was published.
Response:
noted, refer to US comment 121.
>
FCD TECHNICAL #125
>
The US thanks the Irish NB for responding to the US comments on the Irish
example.
Response:
noted.
>
Annexes E and F
>
* Annex E, "reorder-after" construct in POSIX LC_COLLATE
>
* Annex F Information on "reorder-after" construct in LC_COLLATE)
>
FCD TECHNICAL #126
>
Critical issue: Must be resolved to the satisfaction of the US to reverse vote
>
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).
>
DoC on CD2 TECHNICAL #75
>
Not accepted. These specifications relate also to POSIX locales and not just to
>
14651.
>
Remove both Annex E and Annex F.
>
Rationale:
>
1. The Editor has failed to address the following US concern:
>
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.
>
2. This FCD is for a procedural standard, so it cannot define normative
syntactic additions that apply to the technical content of ISO/IEC 9945.
>
3. ISO/IEC 9945 is the responsibility of SC 22/WG 15. Such additions must be
made through a revision of ISO/IEC 9945.
Response:
Accepted in principle. Text added in the beginning of annex E:
This
is an extension technique for use with locale which are otherwise compliant
with
ISO/IEC
9945. This extension technique may be used in registration applications
according
to this International Standard."
Title
changed to "... construct in LC_COLLATE". These changes meet
the US concerns
about
adding normative capabilities to POSIX in this standard.
>
Clause E.3 Example of "reorder-after"
>
FCD TECHNICAL #127
>
DoC on CD2 TECHNICAL #76
>
Not accepted. <AA> and <aa> stands for Å and å respectiviely.There
is no defiency. This will be clarified.
>
The US appreciates that, despite this DoC, some of its comments have been
incorporated into Annex E of the FCD.
>
>
item 5
>
FCD text begins:
>
5. A complete example for Danish using characters from ISO/IEC 10646 is
included in Annex G.1. For the sequence:
>
and continues after the sequence:
>
the example reordering in E.3.1 gives:
>
Delete
>
E.3.1
>
and substitute:
>
Annex G.1.
>
Rationale: Clause E.3.1 does not exist. The US presumes that the intended
reference is to Annex G.1.
Response:
accepted.
>
Annex H Differences from ISO/IEC 15897:1999 and CEN ENV 12005:1996
>
>
H.2 Changes from CEN ENV 12005:1996
>
FCD OBSERVATION #128
>
The second paragraph of clause H.2 states that references are to the 1999
edition of ISO/IEC 15897. Clause H.2 describes a stable situation. Changes to
clause designations are not needed.
Response:
noted.
>
Bibliography
>
>
FCD TECHNICAL #129
>
4th citation (incorrectly numbered "3"):
>
CEN ENV 13710:2000, European Ordering Rules
>
Incomplete title. Full title is:
>
European Ordering Rules - Ordering of characters from the Latin, Greek and
Cyrillic scripts
>
Rationale: Information from CEN document catalogue
http://www.cenorm.be/catweb/35.040.htm
Response:
accepted.
>
FCD TECHNICAL #130
>
Should this more recent CEN standard
>
CR 14400:2001 European ordering rules - Ordering for Latin, Greek, Cyrillic,
Georgian and Armenian scripts
>
be substituted for CEN ENV 13710:2000?
>
>
Note: CEN ENV 13710:2000 is given as an example in clause 11.1 Contents
of Narrative Cultural Specification, [NCS] Clause 1: Alphanumeric deterministic
ordering.
Response:
accepted.
>
End of Specific Technical Comments
>
>
>
>
SPECIFIC EDITORIAL COMMENTS
>
Introduction
>
>
first paragraph, last sentence
>
FCD text:
>
This edition adds of the International Standard adds support for registering
specifications meant for machine processing such as ISO/IEC TR 14652
specifications, SGML and XML, it enlarges the group of organizations that may
be Sponsoring Authorities, and an effort has been done to align it with the
registration procedures of ISO/IEC 2375.
>
Corresponding CD2 text:
>
This edition of the International Standard adds support for ISO/IEC TR 14652,
SGML and other techniques meant for machine processing, and enlarges the group
of organizations that may be Sponsoring Authorities.
>
FCD EDITORIAL #131
>
Delete
>
"This edition adds of the International Standard adds support for
registering..."
>
and substitute:
>
"This edition of the International Standard adds support for
registering..."
>
Rationale: Grammar
Response:
Accepted.
>
FCD EDITORIAL #132
>
Change "done" to "made".
>
Rationale: Style.
Response:
Accepted.
>
FCD EDITORIAL #133
>
The sentence is now excessively long, and ought to be split in two. The
preceding corrections have been applied to the following proposed text.
>
This edition of the International Standard adds support for registering
specifications meant for machine processing, such as ISO/IEC TR 14652
specifications, SGML and XML, and also enlarges the group of organizations that
may be Sponsoring Authorities. An effort has been made to align the
registration procedures of this standard with those of ISO/IEC 2375.
Response:
Accepted in principle. Text ", and also" will be changed to ".
It".
>
2 Normative references
>
>
FCD EDITORIAL #134
>
Insert blank line between entries for ISO 4217 and ISO 8601/
Response:
Accepted
>
3 Terms and definitions
>
>
FCD EDITORIAL #135
>
Critical issue: Must be resolved to the satisfaction of the US to reverse vote
>
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:
>
??????????: ??????? ???????? ????????????? ?? ??????? ? ???????????? ??????
????? ????????? ?? ?????????? ?????.
>
DoC on CD2 EDITORIAL #82
>
Not accepted. ISO 2382 does it this way.
>
ISO/IEC 2382 is an independent terminology standard (published in multiple
parts) that defines the vocabulary of the field designated variously as
information technology (parts published since 1990), information processing
systems (parts published 1986-89), and data processing (parts published up to
1985). For such a standard, the ISO/IEC Directives, Part 2 says that a
classified arrangement is preferable (clause C.2.1, first paragraph).
>
Using ISO/IEC 2382 as a model for this standard's short clause on terms and
definitions is totally inappropriate, and potentially confusing to users. 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.
Response:
withdrwan by the
cross-references
with the renumbering.
>
FCD EDITORIAL #136
>
Rationale: ISO/IEC Directives: Part 2, clause C.3.3 states that a definition
must begin with a lower case letter "except for any capital letters
required by the normal written form in running text".
>
>
Note: Clauses 3.10 and 3.11 are correct.
Response:
Accepted.
>
FCD EDITORIAL #137
>
In all clauses (3.1 to 3.11), delete the trailing full-stop (period).
>
Rationale: ISO/IEC Directives: Part 2, clause C.3.3 states that a definition
"shall not be followed by a full-stop".
Response:
Withdrawn by the
>
3.7 cultural specification
>
FCD EDITORIAL #138
>
"...such as ...XML."
>
Phrase is partly duplicative with respect to TR 14652.
Response:
Accepted. See also response to
>
7.1 Identity [of the Sponsoring Authority]
>
>
FCD EDITORIAL #139
>
If CEN TC 304 is retained as one of the organizations which may function as a
Sponsoring Authority:
>
1. Change designation of second-last item from "b" to "c".
>
2. Change designation of last item from "c" to "d".
Response:
Moot. See response to US comment 28.
>
FCD EDITORIAL #140
>
At the end of the last item, change trailing semi-colon to full-stop (period).
Response:
Accepted.
>
7.2 Responsibilities [of the Sponsoring Authority]
>
FCD EDITORIAL #141
>
The text which was accepted was further modified by the Editor to reflect the
content of a new clause, 8 Source of Information, added in response to US
comment #27. Item (a) in the FCD now is:
>
a) to receive applications concerning Cultural Specifications from a Source of
Information, such as organizations, firms or experts, operating in the area
over which the Sponsoring Authority has jurisdiction.
>
Delete the comma following "Information" and this text (including the
trailing comma):
>
such as organizations, firms or experts,
>
and substitute
>
(see clause 8)
>
Rationale: This clause now refers to the Source of Information. The Source of
Information is defined in clause 8. It is inappropriate to define it here as
well.
Response:
Accepted.
>
>
8.1 Identity [of Source of Information]
>
Text: of new clause in FCD:
>
The Source of Information is an organization or person that has authored the
Cultural Specification.
>
>
FCD EDITORIAL #142
>
Change
>
an organization or person that has authored
>
to
>
the organization or individual responsible for
>
Rationale:
>
1. Consistency with the comparable clause, 7 Owner of Origin, in ISO/IEC
2375:2003.
>
2. Clarifies that the Source of Information is responsible for the content of
the Cultural Specification.
>
Note: The US considers that "organization or individual" adequately
covers the phrase "organizations, firms or experts" proposed for
deletion from clause 7.2, item (a).
Response:
Accepted.
>
>
8.2 Responsibilities
>
FCD EDITORIAL #143
>
Line 1: Change "Source of information" to Source of
Information".
>
Rationale: Consistency.
Response:
Accepted.
>
Clause 10.2 Relations between registration types
>
>
FCD EDITORIAL #144
>
Insert the following text as a second paragraph.
>
The POSIX Locale shall define all standard categories. Individual categories may
be copied from another Locale. See Annex G for examples.
>
Rationale: Brings together all requirements for a POSIX Locale in one place in
the standard.
Response:
Withdrawn by the US.
>
FCD EDITORIAL #145
>
Change "hall" to "shall".
>
Rationale: Correction of typo.
Response:
accepted.
>
Clause 10.2.4
>
FCD EDITORIAL #146
>
Critical issue: Must be resolved to the satisfaction of the US to reverse vote
>
Current text:
>
The ISO/IEC 15897 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.
>
Change the initial "The" to "A"
>
Rationale: To reflect the rewording of clause 10.2.3.
Response:
accepted. Note: Rationale applies to 10.2.4, not 10.2.3.
>
Clause 10.2.5
>
FCD
EDITORIAL #147
>
Delete the first sentence:
>
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 may refer to a corresponding Narrative Cultural
Specification.
>
and substitute:
>
A TR 14652 FDCC-set or other machine-parsable cultural specification shall
specify in formal syntax some aspects of a Narrative Cultural Specification,
and may refer to a corresponding Narrative Cultural Specification.
>
Rationale: Stylistic improvements to clarify instruction.
Response:
See US comments 44 and 45.
>
FCD EDITORIAL #148
>
Insert the following text as a second paragraph.
>
The FDCC-set shall define all standard categories. Individual categories may be
copied from another FDCC-set. See Annex G for examples.
>
Rationale: Brings together all requirements for an FDCC-set in one place in the
standard.
Response:
See US comments 44 and 45.
>
Clause 10.2.6
>
FCD EDITORIAL #149
>
In the first sentences, change "In case" to "In the case".
>
Rationale: Proper English usage, and consistency with rewording requested in
FCD TECHNICAL #46 .
Response:
accepted
>
Clause 11.1 Contents of Narrative Cultural Specification
>
>
FCD EDITORIAL #150
>
Insert "a" between "of" and "Narrative".
Response:
accepted
>
Clause 3: Numeric formatting
>
FCD EDITORIAL #151
>
Delete "gouping" [sic]
>
Rationale:
>
1. Does not appear in the US text which was accepted in the DoC.
>
2. "Grouping" is redundant and confusing. The word
"separator" implies grouping.
Response:
accepted
>
Clause 20: Numbering, ordinals, and measuring systems
>
FCD EDITORIAL #152
>
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).
>
DoC on CD2 N1020
>
Noted. No such text is needed.
>
While the US considers that its proposed text to be better stylistically than
the current text in the FCD, the defects noted in CD2 EDITORIAL #127 have been
corrected.
>
>
Clause 13 Rules for Cultural Specifications
Response:
Noted.
>
FCD EDITORIAL #153
>
Change title of the clause to:
>
Format of registration documents
>
Rationale: This clause describes the formats of the various documents that make
up a registration for a cultural specification.
Response:
Not accepted.
>
13.1
>
FCD EDITORIAL #154
>
US comment CD2 TECHNICAL #33 on clause 9.3.1 was accepted. Corresponding text
in FCD reads:
>
An application for registration of a Cultural Specification shall be submitted
as a Text File. A Narrative Cultural Specification may alternatively be
submitted on paper, preferably A4, or one of the approved document formats of
ISO/IEC JTC 1, as noted in the JTC 1 directives, Annex H.4.
>
Change "directives" to "Directives".
>
Rationale: JTC 1 practice (see, for example: clause 7.4.2.3.10 of the JTC 1
Directives).
Response:
Accepted.
>
Clause 14 Specification of the token identifier
>
>
Clause 14, first paragraph
>
FCD EDITORIAL #155
>
The last sentence reads:
>
The maximum lenght of a token identifier is 200 characters.
>
"length" is misspelled.
Response:
Accepted.
>
15 Initial registration procedures
>
>
Clause 15.3
>
FCD EDITORIAL #156
>
If the application fails to meet this requirement, the application shall be
rejected.
>
Change "this requirement" to "either of these requirements"
>
When requested by the RA, the RA-JAC may provide an opinion on whether an
application satisfies this requirement.
>
Change "this requirement" to "these requirements"
>
Rationale: Required grammatical change if additional item is added.
Response:
accepted.
>
>
FCD EDITORIAL #157
>
1) Change "RA" to "Registration Authority" (two
occurrences).
>
Rationale: For consistency with "Sponsoring Authority/Authorities" in
this paragraph.
Response:
accepted.
>
>
Clause 15.4
>
FCD EDITORIAL #158
>
Bullets missing from items in clause 15.4.
Response:
Accepted.
>
Clause 15.5
>
FCD EDITORIAL #159
>
Bullets missing from items in clause 15.5.
Response:
Accepted.
>
Clause 15.6
>
FCD EDITORIAL #160
>
three-month information and comment period
>
Delete "three-month" and insert "of 90 days" after
"period".
>
Rationale: Consistency with other periods expressed as number of days.
Response:
Accepted. (for clause 15.8)
>
16 Processing of an approved application
>
>
Clause 16.1
>
FCD EDITORIAL #161
>
Bullets missing from items in clause 16.1.
Response:
Accepted.
>
Clause 16.6
>
FCD EDITORIAL #162
>
The Registration Authority shall announce publication of the registration to
subcommittee responsible for maintaining this standard.
>
Insert "the" between "to" and "subcommittee".
>
Note: This omission was in the text supplied by the US,
Response:
Accepted.
>
17 Appeal procedures
>
>
FCD EDITORIAL #163
>
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.
>
DoC on CD2 EDITORIAL #106:
>
Not accepted. The text is introductory, and does not harm.
>
Not only is this line redundant, it is a hanging paragraph which. "should
be avoided since reference to them is ambiguous." (ISO/IEC Directives,
Part 2, clause 5.2.4)
Response:
Accomodated by resolution of US comment 101
>
Clause E.3 Example of "reorder-after"
>
FCD EDITORIAL #164
>
This clause ends with a note:
>
Note: The characters on the last line are the following, with UCS short
identifiers:
>
Make the following changes:
>
1. Delete "Note:" and substitute "NOTE".
>
2. Indent the note (including the UCS short identifiers).
> Rationale: ISO/IEC Directives, Part 2, clause 6.5.1.
The last
paragraph of this clause states:
>
In drafts, all lines of a note or example shall be inset from the margin or
shall be set in smaller type, so that its extent can be determined.
Response:
accepted
>
Annex H Differences from ISO/IEC 15897:1999 and CEN ENV 12005:1996
>
>
H.1 Changes from ISO/IEC 15897:1999, item 3
>
FCD EDITORIAL #165
>
FCD text:
>
3. The text was revised to align with the new ISO/IEC 2375 International
Standard, which the original wordings in the CEN ENV 12005 was built from.
>
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.
>
DoC on CD2 EDITORIAL #110
>
Accepted in principle, but the history will be retained.
>
Reword as:
>
3. The text was revised to align with International Standard ISO/IEC 2375:2003.
>
Rationale:
>
1. ISO/IEC 2375 now has a publication date.
>
2. The assertion that CEN ENV 12005 is based upon the "new ISO/IEC
2375" is impossible because of the dates of publication. CEN ENV 12005 was
published in 1996, the new edition of ISO/IEC 2375 was not published until
seven years later. Furthermore, the lack of parallelism between ISO/IEC
2375:2003 (as of its FCD stage) and ISO/IEC 15897:1999 (which was fast-tracked
from CEN ENV 12005) is recorded in WG20 document N945R.
>
Note: If CEN ENV 12005 was based upon an earlier edition of ISO/IEC 2375, this
information belongs in clause H.2, where CEN ENV 12005 is discussed.
Response:
Accepted.
>
Bibliography
>
>
FCD EDITORIAL #166
>
Citation 3: Add the URL for the RFC:
http://www.ietf.org/rfc/rfc3066.txt?number=3066
Response:
Withdrawn by the
>
FCD EDITORIAL #167
>
Change the number of the 4th citation from "3" to "4".
Response:
Accepted.
>
>
FCD EDITORIAL #168
>
Change the number of the last citation from "4" to "5".
Response:
Accepted.
>
End of Specific Editorial Comments
>
End of US Comments
With
these dispositions of comments the
from
"no" to "yes".