ISO/IEC JTC1/SC22/WG20 N1019 Title: Disposition of comments on ISO/IEC 15897 CD 2, SC22 N3541 Source: ISO/IEC JTC1/SC22/WG20 Status: draft 2 Date: 2003-02-21 > SUMMARY OF VOTING ON > Letter Ballot Reference No: SC22 N3523 > Circulated by: JTC 1/SC22 > Circulation Date: 2002-11-08 > Closing Date: 2003-02-08 > > SUBJECT: Summary of Voting on SC 22 N 3523, Text for Second CD Ballot, > ISO/IEC CD 15897 - Procedure for the Registration of Cultural Elements > ---------------------------------------------------------------------- > The following responses have been received on the subject of approval: > "P" Members supporting this appointment > 6 (China, Czech Republic, Denmark, Republic of Korea, Norway, Switzerland) > P" Members supporting this appointment, with comments > 1 (Germany) > "P" Members not supporting this appointment > 4 (Japan, Netherlands, UK, USA) > "P" Members abstaining > 2 (Austria, France) > "P" Members not voting > 11 (Belgium, Brazil, Canada, Egypt, Finland, Ireland, DPR of Korea, Romania, > Russian Federation, Slovenia, Ukraine) > Note: O-member Sweden voted to approve Also Canada voted positively on the CD. > ___________ end of summary, beginning on NB comments _____________ > Germany > > editorial comments: > > 9.2.8 > > "but need not refer" --> "may refer" Accepted. > Annex D.2 > > Check the printing > > Technical comments: > > Introduction: > > Add "XML" after SGML in the introduction and passim (of course, XML is > implied by SGML, but better be explicit) Accepted. > 4.4 text-file > > "A file" --> "A human-readable file" (or similar) Accepted. > 5.5 "No modification..." > > Allow versioned registrations / updates to existing registrations, > provided all older versions are still accessible and can be uniquely > identified (to a degree, this possibility is implied by Annex A, point > 14) Accepted in principle. Some text will be added to say that updates are done with version numbers etc. > 7.3 Identity > > Create and quote a URL for registrations in Russian The comment was withdrawn. > 9.3.7, point 9 > > Add note on registratiosn for the European Union (EU) Accepted. The EU designator will mentioned here. > 9.4 "contents of a narrative cultural specification" > > General: > > The list of optional clauses is fairly arbitrary. However, all such > lists are more or less arbitrary, so no change is required at this point > beyond a note that should point out that the list of optional clauses > may be open to additions in the future. Accepted. This will be added under the list in 9.3.2 > Clause 1: > > "Multilingual Sorting" --> "Multilingual Ordering" > > The text should refer to ENV 13710 (as it stands, it suggests that > there may be a European Standard in the future, but that it does not > exist already) Accepted. The reference will be added to the bibliography. > Clause 16: > > For curiosity: In which culture are family names capitalized > throughout? France, and sometimes in the EU. The example will be changed to in which order you have the given name and the familiy name. > 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. > > Japan > > There are no market needs for this registration. Noted. The registry is being used, as can be seen from web access and references. > > Netherlands > > GENERAL > > 1 - ISO/IEC 15897 should be a self-contained standard as much as > possible. That means that references to Posix and to 14651 should be > reduced to a minimum, and where necessary, definitions and explanations > should be added, even if this implies copying lines from Posix or > 14651. Partially accepted. A registration standard refers a technical standard for which it registers things, so it is in order to do these references. However, definitions and explanations may be added, where there is an opportunity to clarify the text. > 2 - The reference to CEN TC304 (see clause 8.1) should be removed. Noted. No acction taken pending the determination of the future status of TC304. > SPECIFIC > > We do not have the means to deal with every clause, but we restrict > our comments to 9.4. The central question here is: Does this answer > what industry wants to know? > > Clause 1-6: > Expand the text to explain what is really asked for. For example, > several readers told us that they had no idea what "deterministic > ordering" means. Also, a more logical sequence of clauses would > facilitate answering a questionnaire. Accepted in principle. "Deterministic ordering" and other possibly unclear terms will be will be explained more fully. It is difficult to change the sequence of clauses, for backward compatibility. If you feel that other clauses may be helpful in understanting a specific clause, a reference to that other clause could be added. > Clause 1: > This requires knowledge of the national alphabet, which is only made > available in clause 9. Thus put this clause first. Actually the sequence of clauses can be done as the writer wants. There is some logic in having clause 2 or 9 before clause 1, but it hurts backwards compatibility. A note will be added that references to other clauses can be done. > The question of ordering is repeated in clause 10. Why? What is the > difference? Are there two possible approaches of ordering? > Which of the two produces "culturally expected results"? There may be more than one kind of culturally acceptable ordering, as explained in 9.4.10. Eg telephone directory sorting, soundex ordering. > Clause 7: > This presupposes that such a thing exists. What if it does not? If it does not, you can leave out a description > Clause 9: > This question is worded in such a way that it may be interpreted by > readers quite differently, with as effect that answers are no longer > comparable, to the distress of industry. The clause will be modified for some clearer wording. > Clause 10: > See above. See response above. > > We may continue this way, but the most significant improvement to > 9.4 would be that the questions should no longer put riddles to the > reader, which he cannot solve. A questionnaire in the present style > will > motivate very few people to give honest and true answers. Noted. WG20 is open to suggestions on better wording. > United Kingdom > The WG20 meeting in Tromso agreed that an alignment with the registration > procedures in 2375 should be made; this has only be partially carried > through, leaving a procedure which is far from adequate. In particular it is > not acceptable that a registered set of cultural conventions should only be > checked for conformance to some > format, we need to recognise that a set of cultural conventions could be > transnational and need to be agreed by several national bodies through some > appropriate procedure. Accepted in principle. We expect the procedures to be well aligned with ISO/IEC 2375 due to the resolution of comments on this ballot. There are specific rules for transnational specifications of cultural conventions that ensure that they are checked before submission, such as passing a SC22 vote. Also the procedures as they stand in the current document gives a 3 month review and comment period for the members of SC22, and also for the RA-JAC members. In the end it is however the responsibility of the Sponsoring Authority what will be registered. > USA > > Subject: US Comments on CD2 Text for the Revision of ISO/IEC 15897 > From: US National Body > Date: 2003-01-29 > > References (SC 22/WG 20 documents): > N 893, Summary of voting on CD registration and CD ballot for ISO/IEC CD > 15897. - Registration of cultural elements > N 957, Disposition of comments on CD of 15897 > N 987, Information technology - Procedures for registration of cultural > elements (ISO/IEC CD2 15987:2002(E)) > > Notation: > A substantial number of the US comments on the first CD were not accepted, > for reasons that the US does not agree with. In addition, other US comments > that were accepted (either in actuality or in principle) have not been > adequately incorporated into the text of N 987. If text from an earlier > comment is quoted, the original number of the comment (as it appeared in N > 893 or N 957) is shown, with the prefix "CD1" to distinguish it from > comments on the second CD. > > Organization: > US comments consist of: > * general comments on technical issues and on editorial > issues; > * technical comments on specific clauses; and, > * editorial comments on specific clauses > supplemented by four appendices. > Numbering of US comments on the second CD is continuous (including the > appendices). > GENERAL COMMENTS ON TECHNICAL ISSUES > > General Comment #1 - Technical issue: On use of TR 14652 > As specified in Annex E of the JTC 1 Procedures > (]), registration requires two > standards: > * a technical standard ("The standard containing the > definition of the classes of objects requiring registration"), and > * the procedure standard ("The standard containing the > specific procedures for the JTC 1 Registration Authority to follow") > [Quotations are from Annex E.] ISO/IEC 15897 is the procedure standard. > For a POSIX Locale or definition of a POSIX category, the applicable > technical standard is ISO/IEC 9945:2002. In other clauses, this CD2 > references TR 14652. > TR 14652 is being published as a Type 1 Technical Report rather than as an > International Standard because consensus could not be reached on five > significant topics: LC_CTYPE, LC_MONETARY, LC_TIME, LC_XLITERATE, and > REPERTOIREMAP. All of the clauses dealing with these topics are marked > "controversial," i.e., there are no agreed-upon specifications for these > topics. > In several places, the CD2 references one of the controversial topics in TR > 14652 and sometimes specifies that the controversial topic shall be used > (for example, in Clause 9.3.9). Before a controversial topic can be used, > the controversy must be resolved. If this is not done, the information in > registrations will be unreliable, and there will be problems with > interoperability. > It is unacceptable that there would be an attempt to elevate material that > is specifically labeled "controversial" in TR 14562 to normative status in > ISO/IEC 15897 by specifying its use. Instead, ISO/IEC 15897 must forbid use > of any of the clauses in TR 14652 that are identified as "controversial". > In comments on the "Scope" clause (which is normative), the US has supplied > new text to ensure that this fundamental requirement is met. Not accepted. Agreement was reached in JTC1 to publish TR 14652 as a TR type 1. The controversy has been resolved as documented in TR 14652, but it is noted that there were issues with a number of specifications. 14652 has as a Type 1 TR the status of a trial standard, and 15897 thus enables JTC 1 to collect experience with it. 15897 even allows specifications in freeform notation, so it should also allow something that has been approved in JTC 1 as a trial international standard. > 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. Accepted in principle. There is a review and comment process in the registration standard, that ensures a fair process. The US should note that the Disposition of Comments was produced by the WG20, and not solely by the editor. > GENERAL COMMENTS ON EDITORIAL ISSUES > > General Comment #3 - Editorial Issue: Poor Organization > While CD2 is an improvement over CD1, many of the organizational defects of > CD1 still exist. In particular, organizational changes based on ISO/IEC 2375 > which appear in document N 945R have been disregarded. > Division of the normative general content of this standard (following Terms > and conditions) should be in four basic parts: > * definition of the agencies responsible for this standard and > the procedures defined in it > * definition of the contents of the cultural specification and > layout of the registration documents > * detailed description of the procedures for submission, > review, and approval of an application for registration > * appeal procedures and subsequent procedures associated with > a registration. > Specific US technical comments describe the necessary changes in detail. 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 wil be noted there, and not be dealt with further here. > General Comment US#4 - Editorial Issue: Uncaught errors > >From the number of spelling and grammatical errors in CD2 15897, it is > appears that the Editor did not perform spell-checking and grammar-checking > on the text. This is inadequate and unacceptable -- these functions are > readily available in modern word-processing software (including > language-specific settings). While the Editor may intend to correct such > errors at the final stage (or rely on ITTF to do so), it is preferable to > catch even editorial errors at an early stage of the technical work. The US > considers that every stage of a standard should be as correct in spelling > and grammar as possible. Accepted > General Comment US #5 - Editorial: Titles of clauses > The titles of all clauses should follow the practice used in the ISO/IEC > Directives, Part 2. That is, they should be in lower case, except for the > first letter and any terms that are capitalized in the text of the standard > (for example, "Registration Authority"). > The ISO/IEC Directives, Part 2, do not appear to have specific instructions > on capitalization of the titles of clauses (the relevant clause, 5.2.2 > states only: "Each clause shall have a title, placed immediately after its > number, on a line separate from the text that follows it.)." Accepted: It was clarified that this applies to the ISO clauses, and not to the narrative sepecifications. > End of General Comments > SPECIFIC TECHNICAL COMMENTS > Foreword > CD2 TECHNICAL #5 > The second-last paragraph of the Foreword reads: > This International Standard registers amongst other items > Cultural FDCC-sets, charmaps and repertoiremaps as defined in ISO/IEC TR > 14652, and POSIX Locales and POSIX Charmaps as defined in ISO/IEC 9945-2 > "POSIX shell and utilities". > Delete "and repertoiremaps" > Rationale: As noted above, repertoiremaps are identified in ISO/IEC TR 14652 > as "controversial." Therefore, this International Standard cannot register > "repertoire maps as defined in ISO/IEC TR 14652" because there is no > agreed-upon definition. Not accepted. See response to US comment 1. > Introduction > CD2 TECHNICAL #6 > First paragraph, last sentence, and Second paragraph, first sentence: > Insert "the non-controversial clauses of" before "ISO/IEC TR 14652" in both > places. > Rationale: The clauses of ISO/IEC TR 14652 marked "controversial" shall not > be used. Only the non-controversial clauses may be used. Not accepted. See response to US comment 1. > CD2 TECHNICAL #7 > Second paragraph, second sentence: > In CD1 Objection #4, the US recommended a number of changes, all of which > were "Accepted in principle." One of these recommendations was: > Thus, the sentence should end "...will also be freely > available." > The Editor added the URL for the ISO web pages, but retained the URL for > DKUUG, so that the sentence now reads: > The registration will be free-of-charge and the registered > cultural elements will also be freely available on the network at the > address (and initially at > ). > The CD2 text now implies that the "registered cultural elements" are > available at both URLs. This is incorrect. The ISO "mara" URL yields a list > of registration agencies, not "registered cultural elements". > To eliminate confusion, delete both URLs, so that the sentence ends "... > will also be freely available." as previously recommended. > Rationale: > (a) If the URL for the English language ISO site is given, the > URL for the corresponding French language site should also be given, since > French has equal status with English as an official ISO language. > (b) The URLs duplicate information that is available elsewhere: > (a) Both ISO URLs are published in clause 7.3; > (b) The DKUUG URL is published on the two ISO > sites. > Including them here is excessive and unnecessary detail for an > Introduction. > (c) [From CD1 OBJECTION #4} While DKUUG is the initial > maintainer of these cultural definitions, that could change over time, so it > seems inappropriate to list the address here in the Introduction. > See also comment on clause 7.3. 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. > 1 Scope > First paragraph, middle sentence: > The cultural specifications may include freeform narrative > cultural conventions specifications, POSIX Locales and Charmaps conforming > to ISO/IEC 9945-2, FDCC-sets, repertoiremaps and charmaps following the > recommendations of ISO/IEC TR 14652, and SGML. > Make three changes to this sentence: > CD2 TECHNICAL #8 > Change "ISO/IEC 9945-2" to "ISO/IEC 9945" > Rationale: A new consolidated edition has been published. Accepted. > 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. Not accepted. See response to US comment 1. > CD2 TECHNICAL #10 > Insert "the non-controversial clauses of" before "ISO/IEC TR 14652". > Rationale: The clauses of ISO/IEC TR 14652 marked "controversial" shall not > be used. Only the non-controversial clauses may be used. Not accepted. See response to US comment 1. > 2 Field of Application > CD2 TECHNICAL #11 > Delete this clause and its text. > Rationale: Essentially repeats the last paragraph of the preceding clause. > The US recommended addition of this separate clause (as in ISO/IEC FDIS > 2375) but the ITTF rejected the separate clause when FDIS 2375 was submitted > for publication. The US regrets that it was not better informed when it was > preparing N 945 and its revision. Accepted. > 3 Normative references > CD2 TECHNICAL #12 > N987 includes these citations: > ISO 639:1988, Code for the representation of names of > languages > ISO 639-2:1988, Code for the representation of names of > languages -- Part 2 Alpha-3 code. > Update these two citations as follows: > ISO 639-1:2002, Code for the representation of names of > languages - Part 1: Alpha-2 code. > ISO 639-2:1998, Code for the representation of names of > languages - Part 2 Alpha-3 code. > Rationale: > (a) A new edition of Part 1 was published in 2002. > (b) The date of Part 2 is incorrect. (The date was correct in > the CD1.) Accepted. > CD2 TECHNICAL #13 > A new edition of the ISO/IEC standard for POSIX was published in 2002. This > reference is outdated. > ISO/IEC 9945-2:1993, Information technology - Portable > Operating System Interface (POSIX) -- Part 2: Shell and Utilities. > The US recommends inclusion of all of the parts of the 2002 edition of the > ISO/IEC standard for POSIX: > ISO/IEC 9945-1:2002, Information technology -- Portable > Operating System Interface (POSIX) -- Part 1: Base Definitions. > ISO/IEC 9945-2:2002, Information technology -- Portable > Operating System Interface (POSIX) -- Part 2: System Interfaces. > ISO/IEC 9945-3:2002, Information technology -- Portable > Operating System Interface (POSIX) -- Part 3: Shell and Utilities. > ISO/IEC 9945-4:2002, Information technology -- Portable > Operating System Interface (POSIX) -- Part 4: Rationale. > Rationale: > Previously, Part 2 contained the information about character maps, locales, > the POSIX locale, etc. That information now is in Part 1. > Also, the current Part 4 contains a small sample locale, but does not > contain the Danish locale that was in POSIX.2:1993, Annex G. Accepted in principle. The new references will be added, while the old references will be retained, so we can reference annex G. > CD2 TECHNICAL #14 > All references in this standard must be up-to-date at each stage of the > technical work. > Rationale: ISO mandates (in the text introducing the normative references of > a standard): "For dated references, only the edition cited applies." The > most current version of standards and other normative references must be > cited at each stage, to avoid any oversights later. The result will be > up-to-date information in cultural specifications created according to this > standard. 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. > 4 Terms and definitions > 4.1 locale > CD2 TECHNICAL #15 > Current text: > locale > The definition of the subset of a user's information > technology environment ...See clause 2.5 of the POSIX-2 standard for a > specification of the locale file format. > Problem and Action: > This reference is obsolete. Update the text to refer to the Locale section > in ISO/IEC 9945-1:2002. Accepted. > 4.3 charmap > CD2 TECHNICAL #16 > Current text: > charmap > A text file describing a coded character set. See clause 2.4 of the POSIX > standard for a description of the POSIX Charmap file format... > Problem and Action: > This reference is obsolete. Update the text to refer to the Character Set > section in ISO/IEC 9945-1:2002. Accepted. > 4.6 cultural specification > CD2 TECHNICAL #17 > The definition for "cultural specification" reads: > Either a Narrative Cultural Specification, a related POSIX > Locale, a related FDCC-set, a POSIX Charmap, a ISO/IEC TR 14652 Charmap, a > Repertoiremap, or another machineprocessable description of cultural > conventions. > Insert the following text between "Repertoiremap" and the comma which > follows it: > (except an ISO/IEC TR 14652 Repertoiremap) > Rationale: In ISO/IEC TR 145526, 6 REPERTOIREMAP is marked "controversial". > Since there is no agreement on the specification, an ISO/IEC TR 14552 > repertoiremap shall not be used. Not accepted. See reponse to US comment 1. > CD2 TECHNICAL #18 > Add the term "cultural element" with definition. > Rationale: This standard "sets out the procedures for registering cultural > elements" but the term "cultural element" is not defined. Accepted. It will be defined as a synonym for "cultural convention". > > 5.4.1 Structure of the identifier > CD2 TECHNICAL #19 > The current text of this clause is: > The structure of a token identifier is given in clause 9.3.8. > The Editor needs to insert text describing the structure of the registration > number immediately before the existing text. (In particular, does it have a > maximum length, and is it zero padded?) > Rationale: The current text is inadequate because subclause 5.4, > Identification of an approved registration, specifies two types of > identifiers: "a unique registration number" and "one or more unique token > identifiers." Both identifiers must be described. Accepted. > > 7.2 Responsibilities > CD2 TECHNICAL #20 > Clause 7.2.2 > Add these two additional items at the end of the list: > - corrections and revisions to existing registrations (as > specified in clauses ); > - withdrawal of existing registrations (as specified in > clause ). > Rationale: These are essential maintenance functions. Accepted. > 7.3 Identity > CD2 TECHNICAL #21 > Delete the note about the "initial Registration Authority", including the > URL for the cultural register. > Rationale: > 1) ISO's designated site for this information is its online > database of maintenance agencies and registration authorities (available in > both English and French). ISO set up this site with the specific purpose of > avoiding the need to revise a standard whenever a Registration Authority > changed. > 2) Should DKUUG ever have to give up its duties as Registration > Authority, this information would then be misleading and the standard would > have to be revised. The whole purpose of giving the URL for the online > database of maintenance agencies and registration authorities in the > standard was to avoid revision. > 3) By referring only to a URL instead of providing the name and > address of the currently-designated Registration Authority, this standard is > consistent with JTC1 recommendations on use of the World Wide Web. Not accepted. See response to US comment 7. > 7.4 Registration Procedure > CD2 TECHNICAL #22 > Delete this clause. > Rationale: > (a) The US proposes two new clauses of the topic of registration > procedures. (See New clauses on Registration procedures below.) These new > clauses are more comprehensive and cover all the items in clause 7.4 (except > the incomprehensible item i). > (b) Registration procedures involve several agencies, only one > of which is the Registration Authority. Therefore, a clause describing > registration procedures does not belong in the clause defining the > Registration Authority. > US comments on specific aspects of the text of clause 7.4 of the CD2 appear > in Appendix 1. Because item i is so unclear, the US comment on it is given > below. Accepted. See response to US comments 49, 50 and 51. > Item i > CD2 TECHNICAL #23 > Current text > In the case of comments, to optionally receive text from > commenters to be added to the registration as comments. > In CD1 Objection #14, the US commented: > This text is unclear. Who can submit comments? The > Sponsoring Authority only? The original author(s)? Anyone? If comments are > submitted, is the Registration Authority required to accept and include > them, or can they reject some comments? If so, on what basis do they decide > to accept or reject comments? > Information must be added here that explains who can submit > comments, and what the Registration Authority can do with those comments. > The Editor responded in the DoC: > 14. Noted. probably the SA, RA and the RAC could submit > comments. N 945R will be taken into account. > N 945R has not been taken into account. Except for a grammatical correction, > the text is unchanged. The Editor has failed to add information to the CD to > answer the questions raised by the US in CD1 OBJECTION #14 and also in N > 945R (Who are these "commenters"? Anyone who chooses to send the RA a > comment? And how is such a comment evaluated for accuracy?). > With respect to the Editor's surmise in the DoC, why would the SA be > supplying comments? Why would the RA be supplying comments? (The RA would be > giving specific instructions to the SA, possibly based on comments from > reviewers.) > Clause 7.4 Registration Procedures (d) shows that the RA receives comments > and forwards them to the SA for action. Perhaps one can infer that the > comments in item d are comments from the SC22 and RA-JAC reviews (described > in item c). But the source and processing of the comments in item i are a > total mystery. Accepted. Item i will be clarified that these are only comments from the JAC. > > 8.1 Identity [of the Sponsoring Authority] > CD2 TECHNICAL #24 > Current list of who may submit applications: > a) Any Member Body or Associated Member Body of CEN or > ISO/IEC JTC1, for applications related to the territories for which they > have authority; > b) CEN/TC304 for applications related to the region of > Europe; > c) ISO/IEC JTC 1 and its Subcommitees and Working Groups, > for any applications; > Delete this list and substitute: > a) ISO/IEC JTC 1 and its Subcommittees and Working Groups, for > any applications; > b) CEN/TC304 for applications pertaining to Europe; > c) Any National Body or liaison organization of ISO/IEC JTC1, > for applications limited to the territory or territories for which they have > authority; > d) Any Member Body or Associated Member Body of CEN for > applications limited to the territory or territories for which they have > authority; > Rationale: > The restructuring keeps information pertaining to ISO/IEC JTC 1 separate > from information pertaining to CEN. > "National body" (not "Member body") is the preferred ISO and JTC 1 term > (see, for example, clause 2.2.3 in the JTC 1 Procedures). Accepted in principle. The National bodies will be mentioned first, as these are the primary SAs. Liaisons do not have any authority, and will not be included. > 8.2 Responsibilities > CD2 TECHNICAL #25 > Replace item a > to receive applications concerning Cultural Specifications, > eg. from firms or organizations in the country, or national experts; > with the following text > to receive applications concerning Cultural Specifications > from organizations, firms or experts operating in the area over which the > Sponsoring Authority has jurisdiction. > Rationale: The current wording is inapplicable to CEN/TC 304, which is not > responsible for a particular country. Accepted. > CD2 TECHNICAL #26 > New item > Insert the following text as a new item immediately before item d: > if any material in an application is under copyright, to > include copyright clearance from the copyright holder in the application; > Rationale: If the Sponsoring Authority is submitting material under > copyright, the SA must obtain copyright clearance for it. The SA may require > the organization or individual initiating the application to provide the > copyright clearance. This item replaces the clause on copyright clearance in > N 945R. > Note this amplifies the requirement in clause 9.3.6 > A written application shall accompany the Cultural > Specification and be signed by authorized personnel on behalf of the > contributing organization. It shall release copyrights of the contributed > sources. > and makes it clear that the Sponsoring Authority is obligated to obtain > copyright clearance for any copyrighted material that is included in the > application. Accepted in principle. The copyright may be retained, but the rights on copying and modification needs to be relinguished. See also German comments. > # Source of information > CD2 TECHNICAL #27 > Add new clause and text to be supplied by the Editor. > Rationale: There is an implied assumption that the Sponsoring Authority is > also source of the information in the application. This may not always be > true (see clause 8.2, item a). The two need to be distinguished. Accepted. > # Copyright clearance > Dealt with in new item added to clause 8.2 that makes the Sponsoring > Authority responsible for obtaining copyright clearance. > > Clause 9 Rules for applications > CD2 TECHNICAL #28 > The US strongly recommends that this clause be restructured as shown in > Appendix 2. > Additional US comments on the text of clause 9 (below) refer to individual > clauses by their CD2 numbers. The response to this is recorded in Appendix 2. > Clause 9.1 Types of cultural Specifications > CD2 TECHNICAL #29 > Current text: > Type 4 is for Repertoiremaps defined in this International > Standard (clause 9.3.9) and in ISO/IEC TR 14652. > Change this reference to: > Type 4 is for Repertoiremaps as defined in ISO/IEC TR 14652. > Rationale: Repertoiremaps are listed as controversial in TR 14652 and shall > not be elevated to normative status in this standard. 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. > Clause 9.2 Relations between registration types > Clause 9.2.2 > CD2 TECHNICAL #30 > Current text: > 9.2.2. The POSIX Locale shall specify appropiate aspects of > a Narrative Cultural Specification in formal POSIX syntax. The POSIX Locale > shall refer to the Repertoiremap being used, and should also list a number > of POSIX Charmaps that it can use. > Revise the second sentence as follows: > The POSIX Locale should list one or more POSIX Charmaps it can use. > Rationale: > Since Repertoiremaps are a controversial part of TR 14652, it is > inappropriate for this standard to say that they "shall" be used, thus > elevating them to normative status. > Also, while this text says one should list "a number of POSIX Charmaps", the > examples in Annex G only list one each; if the examples don't even bother to > list "a number," that shouldn't be the recommendation here. Partially accepted. Repertoiremaps ar a part of this standard. See also response to US comment 1. Wording of "one or more" will be added. > Clause 9.2.5 > CD2 TECHNICAL #31 > Current text: > In the case of a TR 14652 FDCC-set, or other > machine-parsable cultural specification, it shall specify in formal syntax > some aspects of a Narrative Cultural Specification, and shall refer to a > corresponding Narrative Cultural Specification. In case of a TR 14652 > FDCC-set it shall refer to the Repertoiremap being used, and should also > list a number of Charmaps that can be used. > Add this sentence at the end of the clause: > A TR 14652 Repertoiremap shall not be used. > Rationale: In ISO/IEC TR 145526, 6 REPERTOIREMAP is marked "controversial". > Since there is no agreement on the specification, an ISO/IEC TR 14552 > repertoiremap cannot be used. Not accepted. See response to US comment 1. > > Clause 9.2.6 > CD2 TECHNICAL #32 > Current text: > In case of a ISO/IEC TR 14652 Charmap, or other > machine-parsable character set descriptions it shall specify aspects of a > Narrative Cultural Specification or an FDCC-set that relate to coded > character sets. In case of a Charmap it shall refer to the Repertoiremap > being used, but need not refer to the FDCC-set nor the Narrative Cultural > Specifications using it. > Add this sentence at the end of the clause: > A TR 14652 Repertoiremap shall not be used. > Rationale: In ISO/IEC TR 145526, 6 REPERTOIREMAP is marked "controversial". > Since there is no agreement on the specification, an ISO/IEC TR 14552 > repertoiremap cannot be used. Not accepted. See response to US comment 1. > > Clause 9.3 Rules for Cultural Specifications > 9.3.1 > CD2 TECHNICAL #33 > Current text: > . . . A Narrative Cultural Specification may alternatively > be submitted on white paper of the approximate size 297 * 210 mm, with > margins of no less than 20 mm, or one of the approved document formats of > ISO/IEC JTC 1,. . . > In CD1 OBJECTION #21, the US commented: > What is the rationale for specifying the paper size here? > Unless there is a good reason, this should be removed. > The Editor responded in the DoC: > 21. Not accepted. The RA has a responsibility to be able to > print the registry.thus all data must fit on a paper size that the RA can > handle. The RA will deliver such prints on A4, which is the common papersize > for such things. > Additional comments on clause 9.3.1: > 1) The reliance on paper conflicts with clause 7.11.3 > Electronic Document Distribution in the JTC 1 Procedures, which states: > Document distribution within JTC 1 shall be done to the > maximum extent possible using the World Wide Web. The details of this policy > are contained in Annex H. > 2) For the convenience of the reader, the source for the > "approved document formats of ISO/IEC JTC1" should be cited. Is this Annex > HA Text Area for A4 and North American Paper Sizes in the JTC 1 Procedures? > 3) Why say "approximate" size, and why describe the actual > paper size? Why not say "A4" paper? > 4) A 20 mm margin at the bottom of the page is in conflict with > Annex HA of the JTC 1 Procedures, where the minimum for the bottom margin is > 28 mm. Does the stated requirement for 20 mm margins apply only to the right > and left margins? The minimum margins specified in Annex HA are: Top 13 mm, > Bottom 28 mm, Left 20 mm, Right 13 mm, although more generous symmetrical > margins are allowed. Accepted. Text will be revised to be "submitted on paper, preferrably A4." > 9.3.2. > CD2 TECHNICAL #34 > In CD1 OBJECTION #22, the US commented: > Section 6.2 contains a very terse list of items that could > appear in a cultural specification. The description of these very terse > items appears in the informative Annex G. This makes the document extremely > difficult to use. When most readers see items like "Inflection" or "Coding > of national entities" with *NO* further explanation, they will have no idea > what is intended. They can go to Annex G, but why is the information there > instead of where it is originally referenced? > The explanation of the items allowable in a cultural spec > should appear in Clause 6 along with the items themselves. > This comment was accepted by the Editor. The text of Annex G has been > incorporated as 9.4, with a very minor change in the introductory paragraph. > However, the intent of the US comment was to eliminate double look-up. > Instead of checking Annex G, the user must now check clause 9.4. The problem > persists. > Additional comments: > 1) The numbered lists in clause 9.3.2 replicate the fuller > information in clause 9.4. This is unnecessary. The US proposes that these > lists be eliminated. We will propose substitute text to improve the > organization of clauses 9.3 and 9.4. > 2) The US notes that the text in Annex G was informative (as > noted in Objection #22). By its incorporation into the technical content of > the standard, its status has been changed to normative. This important > change should have been noted in the Disposition of Comments. Accepted in principle. The US NB is invited to provide revised text for the considreation of the editor. > Clause 9.3.2, last two paragraphs > CD2 TECHNICAL #35 > Current text: > The format of the POSIX Locale and Charmap sources shall be > conformant to ISO/IEC 9945-2, or for POSIX Locales the technique specified > in Annex E. > The format of the Repertoiremap shall be conformant to > clause 9.3.9. > Change the text to: > The format of the POSIX Locale and Charmap sources shall be > conformant to ISO/IEC 9945-1:2002. > A possible format of the Repertoiremap is described in > clause 9.3.9. > Rationale > (a) The reference to 9945 is obsolete. > (b) The US objects to the technique specified in Annex E; it > must not be part of this standard (see CD2 TECHNICAL OBJECTION #37). > (c) As noted before, the TR 14652 Repertoiremap is controversial > and shall not be a normative part of this standard. 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. > > Clause 9.3.3 > CD2 TECHNICAL OBJECTION #36 > Current text: > The POSIX Locale shall define all standard categories (for > example by copying categories of a standard POSIX Locale; examples are given > in annex F). The FDCC-set shall define all standard categories (for example > by copying categories of a standard "i18n" FDCC-set; examples are given in > annex F). > Substitute this text for the current text: > The POSIX Locale and FDCC-set shall define all standard > categories. > Individual categories may be copied from another Locale or > FDCC-set. See Annex G for examples. > Rationale: Annex F contains information on the "reorder-after" construct; > not examples of POSIX locales or FDCC-sets. Annex G contains sample POSIX > locales, but not FDCC-sets. Accepted. > Clause 9.3.4 > CD2 TECHNICAL OBJECTION #37 > Current text: > The coded character set of ISO/IEC 646 International > Reference Version (ISO 2375 registration number 6) shall be used to > represent text for the submitted files. For enhanced network portability it > is recommended that only the invariant part of ISO/IEC 646 (ISO 2375 > registration number 170), which contains 83 graphical characters (including > space), be used... > The US objected to this during the previous ballot, and we renew our > objection. > Remove the second sentence "For enhanced network portability..." > Rationale: Both the 1993 and 2002 versions of the POSIX standards allow all > graphic characters in ISO 646 IRV, and there is no reason to be more > restrictive in this standard. In the DoC to our previous objection, the > Editor's response was: > Not accepted. This is aligned with other specs in the field. > However, it is not aligned with the standard which invented POSIX locales > and charmaps. This difference is egregious and unacceptable. > The US also notes that the Editor provided no information about the "other > specs in the field" which he used to justify the rejection. 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. > CD2 TECHNICAL #38 > Add this sentence at the end of the clause, following "...character names > defined in a Repertoiremap shall be used." > A TR 14652 Repertoiremap shall not be used. > Rationale: In ISO/IEC TR 145526, 6 REPERTOIREMAP is marked "controversial". > Since there is no agreement on the specification, an ISO/IEC TR 14552 > repertoiremap cannot be used. Not accepted. See response to US comment 1. > Clause 9.3.7, second and third paragraphs > CD2 TECHNICAL OBJECTION #39 > Current text: > For Types 1, 2, and 5, Narrative Cultural Specifications, > POSIX Locales, and FDCC-sets and other formal descriptions of cultural > conventions: . . . > For Types 3, 4, and 6, POSIX Charmaps, Repertoiremaps, and > TR 14652 Charmaps and other formal descriptions of character sets: . . . > Revise the text as follows: > For Types 1, 2, and 5, Narrative Cultural Specifications, > POSIX Locales, and Machine-parsable cultural specifications: . . . > For Types 3, 4, and 6, POSIX Charmaps, Repertoiremaps, and > Machine-parsable coded character set specifications: . . . > Rationale: The descriptive names of Types 1, 2, 3, and 4 here match the type > names in Section 9.1, but those for Types 5 and 6 do not. They must. Accepted. > Clause 9.3.7, third paragraph > CD2 TECHNICAL #40 > Add this sentence as a separate line between "10. Suggested Charmap or > Repertoiremap or other name" and "All applications shall contain information > on these items:" > A TR 14652 Repertoiremap shall not be used. > Rationale: In ISO/IEC TR 145526, 6 REPERTOIREMAP is marked "controversial". > Since there is no agreement on the specification, an ISO/IEC TR 14552 > repertoiremap cannot be used. Not accepted. See response to US comment 1. > Clause 9.3.7, third paragraph from end (begins "Note:") > CD2 TECHNICAL #41 > Change "U0020..U007E" to "U+0020..U+007E" > Rationale: ISO/IEC 10646 conventions. Not accepted. This is notation allowed in 10646 and used already. > Clause 9.3.7, last paragraph > CD2 TECHNICAL #42 > The final paragraph of clause 9.3.7 states: > Annex A specifies a form to be filled out for each Cultural > Specification; Annex B gives an example of a completed form." > There is no indication that Annex A is required, although the normative > attribute of Annex A suggests this. The final paragraph should be reworded > as follows: > The form in Annex A shall be included as part of an > application for registration of a Cultural Specification. Annex B gives an > example of a completed form. Accepted. > Clause 9.3.8, third and sixth paragraphs > CD2 TECHNICAL #43 > "National Standardization Organization" is an undefined term. Does it mean a > "National Body" (per ISO and JTC 1 terminology), or is it intended to > include additional organizations that are involved with standardization? Accepted. National Body is intended. > Clause 9.3.9 > CD2 TECHNICAL OBJECTION #44 > Current text: > POSIX Locale, FDCC-set and Charmap sources shall be > specified in a way that is independent of coded character sets, using > character names. Relation between the character names and characters shall > be specified via a Repertoiremap table, giving the character name and the > ISO/IEC 10646 short character ID in the form of Uxxxx or Uxxxxxxxx, and > optionally the long ISO/IEC 10646 character name. It is recommended to use, > whenever possible, character names specified in ISO/IEC 9945-2:1993 Annex G. > The character name and the ISO/IEC 10646 canonical encoding are each > surrounded by angle brackets <>, and the fields shall be separated by one or > more spaces or tabs on a line. If a right angle bracket or an escape > character is used within a name, it shall be preceded by the escape > character. The escape character can be redefined from the default reverse > solidus (\) with the first line of the Repertoiremap containing the string > "escape_char" followed by one or more spaces or tabs and then the escape > character. > Revise the text as follows: > POSIX Locale, FDCC-set and Charmap sources can be specified > in a way that is independent of coded character sets, using character names. > Relation between the character names and characters can be specified via a > Repertoiremap table, giving the character name and the ISO/IEC 10646 short > character ID in the form of Uxxxx or Uxxxxxxxx, and optionally the long > ISO/IEC 10646 character name. The character name and the ISO/IEC 10646 > canonical encoding are each surrounded by angle brackets <>, and the fields > are separated by one or more spaces or tabs on a line. If a right angle > bracket or an escape character is used within a name, it should be preceded > by the escape character. > Rationale: There are several problems with this clause: > (a) Since the previous ballot version of this section, TR 14652 > has been finalized, but much of it, including the Repertoiremap section has > been designated as controversial. Since WG20 did not reach agreement on the > status and syntax of Repertoiremap in TR 14652, it is not acceptable to > elevate it to normative status in this standard. > (b) The previous U.S. objection to referring to the character > names in ISO/IEC 9945-2:1993 Annex G was rejected with this comment: "Not > accepted. There is a reason, namely that you then can reuse a lot of data." > Although we do not consider this a compelling rationale, this reference has > become obsolete since the CD1 was balloted. ISO/IEC 9945:2002 does not > contain an Annex G with the character names referenced here. In ISO/IEC > 9945-4:2002 (Rationale), there is a short sample locale, but it does not use > the vast majority of the names from the 1993 version of Annex G. Since POSIX > no longer includes these character names, this standard cannot do so. > (c) The information about how to redefine the escape character > is inappropriate. The Editor of this standard chooses not to use the default > escape character that POSIX defines, and he is free to do so. But it is not > appropriate in this syntax definition to tell others how to use the same > non-default escape character that he has chosen. Not accepted. For 14652 see response to US comment 1. For the POSIX 1993 spec, this will stil be referenced in the standard, and thus references can be retained. If there is no specification for redefining the escape character, this is not possible according to this spec, so these wordings are needed. > Clause 9.4 Contents of a Narrative Cultural Specification > > Introductory paragraph, first and second sentences: > CD2 TECHNICAL OBJECTION #45 > Current text: > The contents of the Narrative Cultural Specification is > described in some detail in the following. it builds on information from the > POSIX Shell and Utilities standard (ISO/IEC 9945-2) and the Nordic Cultural > Requirements on Information Technology Summary Report. > Revise the text as follows: > The contents of the Narrative Cultural Specification are > described in some detail in the following clauses. The specification builds > on information from the POSIX Base Definitions standard (ISO/IEC > 9945-1:2002) and the Nordic Cultural Requirements on Information Technology > Summary Report. > Rationale: The POSIX reference is out-of-date, there is a grammatical error, > and a typo. Accepted. > Introductory paragraph, third and fourth sentences: > CD2 TECHNICAL #46 > In CD1 OBJECTION #44, the US proposed changing the sentence > . . Clauses 1 to 6 are related to POSIX and the narrative > description should be accompanied by a corresponding POSIX Locale > specification. > to > Clauses 1 through 6 are related to POSIX. > The proposed change was partially accepted; the fourth sentence was added. > However, the text which the US considered inconsistent with other parts of > this standard was not removed. The text now reads: > Clauses 1 to 6 are related to POSIX and the narrative > description should be accompanied by a corresponding POSIX Locale > specification. If a POSIX locale is submitted, it is desirable that it be > accompanied by a related narrative cultural specification. > Strike these two sentences and replace them with this text. > Clauses 1 to 6 are related to POSIX. When a POSIX locale is > submitted, it should be accompanied by a corresponding narrative cultural > specification. > Note that "is desirable" is not needed because use of "should" is specified > in Table G.2 of Annex G Verbal forms for the expression of provisions in > ISO/IEC Directives, Part 2: Rules for the structure and drafting of > International Standards: > The verbal forms shown in Table G.2 shall be used to indicate that among > several possibilities one is recommended as particularly suitable, without > mentioning or excluding others, or that a certain course of action is > preferred but not necessarily required, or that (in the negative form) a > certain possibility or course of action is deprecated but not prohibited. Accepted. > Clause 3: Numeric formatting > CD2 TECHNICAL OBJECTION #47 > Current text: > Here it is described how numbers are keyed in and > formatted,. . .This is a POSIX category. > Delete current text and substitute: > This clause describes how numbers are formatted, including > the format of the decimal point and the thousands separator. This is a POSIX > category. > Rationale: > POSIX contains no information about how numbers are "keyed in", and neither > of the sample cultural narratives in this document include such info, > either. If information about keying in is needed, it should be moved to > Clause 20 Numbering, ordinals and measuring systems, since it isn't part of > this POSIX category. (See comment on Clause 20 for proposed text addressing > how numbers are "keyed in".) Accepted, (for input and output) will be added to the proposed text. > Clauses 7 through 32 > CD2 TECHNICAL #48 > For the guidance of users, the US recommends that the word "(Optional)" be > added at the end of the heading for each of these clauses. (Clause 9.3.2 > indicates, by the use of "may", that clauses 7 through 32 are optional.) > Rationale: Such guidance is particularly important now that the material > from CD1 Annex G has been raised to normative status. > > See Appendix 3 for US technical and editorial comments on the optional > (non-POSIX) clauses. Headings for the individual clauses show the > modification recommended above. Not accepted. It is clear that these clauses are optional from 9.3.2 and adding optional would clutter the titles. It will be made clear in the start of 9.4 clause 7 that these are optional. > New clauses on Registration procedures > CD2 TECHNICAL #49 > Minimum requirements: > 1) Make clause 7.4 Registration Procedure into a top-level > clause and move it so that it immediately precedes clause 10 Appeal > procedures. > 2) Expand the text of clause 7.4 Registration Procedure to > provide a complete description of registration procedures. In particular, > distinguish between procedures carried out prior to approval of an > application for registration and the procedures that follow approval. > 3) Change its title to Registration procedures. > Rationale: > (a) Relocating clause 7.4 brings all procedures > together in successive clauses. > (b) This is a procedural standard, so should > specify procedures completely and clearly. > (c) Title change for consistency with the title > of clause 10. > Alternative preference: > The US would prefer to see the specification of the registration procedures > divided into two separate top-level clauses. These clauses should > immediately precede clause 10 Appeal procedures. The individual clauses are > specified in the next two comments. > Rationale (in addition to items a-c above): To make the standard easier to > use. Accepted, as noted in US comment 50 and 51. > CD2 TECHNICAL #50 > This comment describes the first clause preferred by the US. > Insert a new clause with the title Initial registration procedures preceding > clause 10 Appeal procedures. > The following proposed text is from clause # Registration procedure in N > 945R. "x" indicates the number that identifies this clause as a whole. All > items in clause 7.4 Registration Procedure are covered in the proposed text, > except for item i (see CD2 Technical Comment on this item above). > > x.1 The Sponsoring Authority shall prepare an application for registration > according to clause 9. > x.2 The Sponsoring Authority shall submit an application for registration of > a cultural specification to the Registration Authority. > x.3 The Registration Authority shall examine each application received. It > shall ascertain that > - The applicant is a Sponsoring Authority as identified in clause #. The RA > shall reject applications for registrations which come from sources other > than the Sponsoring Authorities as defined in clause #. The Registration > Authority may refer the applicant to an appropriate Sponsoring Authority if > one can be identified. > - The proposed cultural specification is not identical to one already > registered. > If the application fails to meet either of these requirements, the > application shall be rejected. > When requested by the RA, the RA-JAC may provide an opinion on whether an > application satisfies these requirements. > x.4 The Registration Authority shall also ascertain that > - The application for registration is legible and meets the presentation > requirements of this international standard. See clause . > - The application includes the elements required from the Sponsoring > Authority for the cover page. See clause . > - The application for registration includes any required copyright > permissions and endorsements. See clause . > If the application for registration fails to meet any of these requirements, > the Registration Authority shall inform the Sponsoring Authority of the > changes needed to meet the requirements. > x.5 The Registration Authority shall submit the application to the RA-JAC > for the technical review. The RA-JAC shall ascertain that > - The application is technically in accordance with this International > Standard. > - The application for registration includes the required description of the > cultural specification. See clause . > x.6 The RA-JAC shall report the results of its evaluation to the > Registration Authority and shall describe any technical concerns with the > proposed registration. > x.7 The Registration Authority shall inform the Sponsoring Authority of any > changes needed to satisfy the concerns of the RA-JAC. > x.8 After an application for registration has passed its review by the > Registration Authority and by the RA-JAC, the Registration Authority shall > circulate the application to the members and liaison organizations of the > subcommittee responsible for maintaining this standard for a three-month > information and comment period. > x.9 The Registration Authority shall consider all comments received. The > Registration Authority shall request the RA-JAC to provide expert advice on > the technical comments. The Registration Authority may incorporate comments > resulting from the review specified in clause into the final > registration. > x.10 The Registration Authority shall approve or reject the application for > registration. > x.11 The Registration Authority shall process approved applications in > accordance with clause . > x.12 When an application for registration is rejected, the Registration > Authority shall inform the Sponsoring Authority and provide the reason for > the rejection. > Accepted in princple. What is technical will be clarified as only technical requirements needed for registration, such as conforming to syntax and administrative issues. > CD2 TECHNICAL #51 > This comment describes the second clause preferred by the US. > Insert a new clause with the title Processing of an approved application > between the new clause Initial registration procedures and clause 10 Appeal > procedures. > The following proposed text is primarily from clause Y. Processing of an > approved application in N 945R. "y" indicates the number that identifies > this clause as a whole. > > Following approval of an application for registration, the Registration > Authority shall: > y.1 Assign a new Cultural Specification identifier as follows: > - Identifiers shall be allocated in ascending order. This allocation shall > only be made immediately prior to publication of the registration, that is, > after completion of all procedural steps. > - No identifiers shall be reserved for future registration applications. > - An identifier, once allocated to a registration, shall never be > re-allocated for another registration. > y.2 The Registration Authority may also assign one or more token identifiers > to the approved registration. > - If the Cultural Specification is identical to one already registered, the > new token identifiers shall be added to the existing registration, and the > addition shall be noted in the version history of that registration; > y.3 The Registration Authority shall note the date of approval in the > registration. > y.4 The Registration Authority shall publish the approved registration in > the ISO/IEC 15893 register. > y.5 The Registration Authority shall notify the Sponsoring Authority of the > publication of the registration. > y.6 The Registration Authority shall announce publication of the > registration to subcommittee responsible for maintaining this standard. > See response to US comment 49. > 10.1 Appeals against rejection > CD2 TECHNICAL OBJECTION #52 > Current text: > The Registration Authority shall accept an appeal from the > Sponsoring Authority against rejection of an application, but only for this > reason: > - disagreement with the Registration Authority on whether > the application meets the technical or administrative requirements for a > registration in clause 9. > Reword as: > If the Registration Authority rejects an application, the > Sponsoring Authority may appeal that rejection based only on whether the > application meets the technical or administrative requirements for a > registration as described in clause 9. > Rationale: Unclear text; > Note: This is a revision of what the US originally asked for. The wording in > 2375 was an attempt to change the wording of the earlier edition as little > as possible. Accepted. > Appeals against registration > CD2 TECHNICAL #53 > Clause 7.2 of the first CD addressed objection by a Member Body to > forthcoming publication of a registration. There is no corresponding clause > in CD2 15897. > To remedy this oversight: > 1) Renumber clauses 10.2 through 10.4 as 10.3 through 10.5. > 2) Insert clause 10.2 Appeals against registration with the > following text and numbering: > > 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 . > 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. > Not accepted. NBs can comment on the application, but the SA will have the final word. > 10.3 Procedure for filing an appeal > CD2 TECHNICAL #54 > Make the following changes which appear in N 945R but were not included in > CD2 15897: > First line: After "registered mail", insert a comma followed by this text: > facsimile, or electronic mail > Rationale: Consistent with JTC 1 recommendation in clause 7.11.2 Use of > Electronic Messaging in Procedures for the technical work of ISO/IEC JTC 1). > First bullet: Change "90" to "30" > Second bullet: Change "90" to "30" > Rationale: These are the periods in ISO/IEC 2375: 200x. Accepted. > 10.4 Resolution of an appeal > CD2 TECHNICAL #55 > Most of clause 7.5 Resolution of an appeal was incorporated into the CD2, > but clause 7.5.3 (dealing with resolution of an objection by a National Body > to forthcoming publication of a registration) was omitted. To correct this > error: > 1) Renumber clause 10.4.3 as 10.4.4 > 2) Insert clause 10.4.3 and the following text (from clause > 7.5.3 in N 945R) > > 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. > Not accepted. See response to US comment 53. > CD2 TECHNICAL #56 > Clause 10.4.4 (= 10.4.3 in CD2 15897): > Make the following two changes to this clause: > 1) Delete the following text (including the misspelling of "receipt"): > by the Registration Authority within 90 days after the reciept of an appeal > Rationale: Communication with the "P-members of the subcommittee responsible > for the maintaining of this International Standard" is the responsibility of > the subcommittee's Secretariat. (The Registration Authority is, of course, > responsible for making arrangements with the Secretariat.) > 2) Change this text: > to decide according to its voting procedures. > to > according to the Procedures for the technical work of ISO/IEC JTC 1. > Rationale: Since this is a JTC 1 standard, JTC 1 procedures apply. The same > wording appears in ISO/IEC 2375:200x. > Note that the recommended wording in N 945R:"for vote according to the > Directives for technical work of ISO/IEC" is taken from an earlier stage of > ISO/IEC 2375:200x. Not accepted. SC22 may have additional procedures beyond the JTC 1 procedures. > 11 The Registration Authority's Joint Advisory Committee > CD2 TECHNICAL #57 > Relocate this clause immediately after clause 8 Sponsoring Authority. > Rationale: Brings all agencies defined by this standard together. Accepted. > Note: For the convenience of reviewers, other changes to the text of clause > 11 of the CD2 are described here. > > Clause 11.1 > CD2 TECHNICAL #58 > Make the following changes to this clause: > 1) Add this title: > Membership > Rationale: For consistency with changes to clauses 11.2 and 11.3. > 2) Delete the last paragraph: > The Registration Authority may request the RA-JAC to provide > expert technical advice on comments. > Rationale: Does not belong in a clause specifying the composition of the > RA-JAC. The responsibilities of the RA-JAC are listed in clause 11.3. 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. > Clause 11.2 > CD2 TECHNICAL #59 > Add this title to clause 11.2: > Appointment > Rationale: For consistency with other clauses describing agencies (for > example, 7 Registration Authority). Accepted. > Clause 11.2, first paragraph > CD2 TECHNICAL #60 > Current text: > The subcommitee responsible for maintaining this standard > shall appoint the members of the RA-JAC, except for the RA representative, > which is appointed by the RA. The subcommitee shall appoint or confirm the > members of the RA-JAC at its plenary meetings. > N 945R says to delete this phrase: > except for the RA representative. > because there is no indication of who appoints the RA representative to the > Joint Advisory Committee. The resulting paragraph then specifies that all > members of the Joint Advisory Committee (including the individual who > represents the RA) are appointed by the subcommittee responsible for > maintaining this standard (i.e., by SC22). > The Editor did not delete the phrase and added a clarification, so that the > corresponding text in the CD2 now reads: > except for the RA representative, which is appointed by the RA. > This new text is unacceptable to the US for the following reasons: > a) It conflicts with the provisions of the second paragraph of > this clause, which clearly states that the subcommittee (i.e., SC22) > determines the members of the Joint Advisory Committee: > The subcommitee shall appoint or confirm the members of the > RA-JAC at its plenary meetings. > b) It conflicts with the provisions of ISO/IEC 2375:200x. It > was WG20's intent to model the administrative aspects of this revision of > ISO/IEC 15897 on the thoroughly reviewed text of ISO/IEC 2375:200x. > c) It is unnecessary. The wording "representative of the > Registration Authority" was used in clause 11.1 to provide flexibility in > case it is not possible for the person carrying out the duties of the > Registration Authority to attend meetings of the Joint Advisory Committee. > It is essential for the Registration Authority to be represented at these > meetings. The expectation is that the person carrying out the duties of the > Registration Authority would normally be chosen by the supervisory body for > this standard (i.e., SC22) for appointment as the "representative of the > Registration Authority". 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. > Clause 11.2, second paragraph > CD2 TECHNICAL #61 > Insert this text after "subcommittee" > responsible for maintaining this standard > to indicate explicitly which subcommittee makes the appointments. Accepted. > Clause 11.3 > CD2 TECHNICAL #62 > Add this title to clause 11.3: > Responsibilities > Rationale: For consistency with other clauses describing agencies (for > example, 7 Registration Authority). Accepted. > CD2 TECHNICAL #63 > Keep this introductory text "The responsibilities of the RA-JAC shall be as > follows:" and substitute the following text (based on #.4 in N 945R and > clauses 11.1 and 11.3 of CD2) for the remainder of the clause. > > - 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. > Accepted. > Additional clauses > Insert 4 new clauses before Annex A. The clauses are described separately > below. They are numbered 12 - 15, since the clause 11 is the last clause in > the main text of CD2. > > New clause: 12 Corrections > CD2 TECHNICAL #64 > Add a new clause with the title: > Corrections > and the following text (from the corresponding clause in N 945R): > > 12.1 The Registration Authority for ISO/IEC 15987 in conjunction with the > Sponsoring Authority shall correct material errors to the information > included in a registration, for example typographical errors, as soon as > detected. > 12.2 The Registration Authority shall add the date of the correction to the > corrected pages, add the date and reason for the change to the cover sheet, > and publish the new corrected pages of the registration. > 12.3 The Registration Authority shall notify the subcommittee responsible > for maintaining this standard and the Sponsoring Authority that a > registration was corrected with the nature of the correction and the date. > > > Note that this clause conflicts with the idea expressed in clause 5.5 that a > new registration is required to make a "correction", presumably even a > typographic correction. Not accepted. Corrections are done by new registrations. The issue will be handled in 5.5, see also German comments. > New clause: 13 Revisions > CD2 TECHNICAL #65 > Add a new clause with the title: > Revisions > and the following text (from the corresponding clause in N 945R): > > 13.1 In general, no changes to the content of a registration are permitted, > as this would be contrary to the principles on which the registrations are > based. > 13.2 When a new registration application is based on an existing > registration, then the Registration Authority shall create a new > registration. The Registration Authority shall also add cross-reference > notes to the two registrations. > Accepted in principle. This would probably not be a full clause, and it should be combined with the text in US comment 66. > New clause: 14 Additions to an existing registration > CD2 TECHNICAL #66 > Add a new clause with the title: > Additions to an existing registration > and the following text (from CD2, clause 7.4, item f): > > When a Cultural Specification submitted for registration is identical to one > already registered, the token identifier(s) for the application shall be > added to the existing registration; > > > 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. Accepted. > New clause: 15 Withdrawal > CD2 TECHNICAL #67 > Add a new clause with the title: > Withdrawal > and the following text (based on the corresponding clause in N 945R): > > 15.1 Withdrawal is a formal declaration by which the Sponsoring Authority > informs the Registration Authority that it withdraws its support of a > registration application or of all or part of an existing registration that > it has sponsored. > 15.2 Such a declaration may, but need not, be accompanied by a statement of > the reasons for the withdrawal. > 15.3 Withdrawal of an application for registration > 15.3.1 When the Registration Authority is notified, it shall take no further > action to process the application. > 15.3.2 If the application for registration is being circulated for comment > according to clause x.8 (in Initial registration procedures), the > Registration Authority shall notify the members of the subcommittee that the > application has been withdrawn by the Sponsoring Authority. > 15.4 Withdrawal of an entire existing registration > 15.4.1 After withdrawal, the registration shall remain in the register and > continue to be identified by the allocated numeric identifier. > 15.4.2 After the date of withdrawal, the Registration Authority shall issue > a new cover page for the registration and shall note on it that the > registration has been withdrawn by the Sponsoring Authority. If the > Sponsoring Authority has given a reason for the withdrawal, this may be > noted in the registration. > 15.4.2 After the date of withdrawal, the Registration Authority shall issue > a new cover page for the registration and shall note on it that the > registration was withdrawn by the Sponsoring Authority and give the date of > withdrawal. When the Sponsoring Authority has given a reason for a > withdrawal, the reason may be noted in the registration. > 15.4.3 The Registration Authority shall inform the subcommittee responsible > for maintaining this standard interested parties of the withdrawal of a > registration. > 15.5 Withdrawal of part of an existing application > 15.5.1 After withdrawal, the registration (including the withdrawn part) > shall remain in the register and continue to be identified by the allocated > numeric identifier. > 15.5.2 After the date of withdrawal, the Registration Authority shall issue > a new cover page for the registration and shall note on it the part(s) of > the registration that were withdrawn by the Sponsoring Authority. The > Registration Authority shall also annotate a withdrawn part to show that it > was withdrawn and give the date of withdrawal. When the Sponsoring Authority > has given a reason for a withdrawal, the reason may be noted in the > registration. > 15.4.3 The Registration Authority shall inform the subcommittee responsible > for maintaining this standard interested parties of the withdrawal of a > registration. > Accepted in principle. Partial withdrawals will not be allowed, and the text on this removed. > Annex A Application form for a Cultural Specification > Items 8, 9 and 10 > CD2 TECHNICAL OBJECTION #68 > Current text: > For Narrative Cultural Specifications, POSIX Locales or > FDCC-sets and other formal descriptions of cultural conventions (type 1, 2, > and 5): . . . > For POSIX Charmaps, Repertoiremaps, or TR 14652 Charmap and > other formal descriptions of character sets (type 3, 4 and 6):. . . > Revise the text as follows: > For Narrative Cultural Specifications, POSIX Locales or > Machine parsable cultural specifications (type 1, 2, and 5): . . . > For POSIX Charmaps, Repertoiremaps, or Machine-parsable > coded character set specifications (type 3, 4 and 6):. . . > Rationale: The descriptive names of Tues 1, 2, 3, and 4 here match the type > names in Section 9.1, but those for Types 5 and 6 do not. They must. accepted > Annex C External References to Cultural Specifications > C.3 Object Descriptors > CD2 TECHNICAL OBJECTION #69 > Current text: > The object descriptors for the abstract syntax object identifiers defined in > 2 above shall be . . ., as assigned per clause 4 responsibility g): > Change the reference to: > ...as assigned in clause 7.4, responsibility f): > Rationale: The reference is incorrect. Accepted. > C.4 Transfer Syntax > CD2 TECHNICAL OBJECTION #70 > Current text: > The transfer syntax as specified in ISO 8824 defines the > encoding in which the contents of a registry entry might be transferred over > a network. For this purpose the transfer syntaxes as defined in ISO/IEC 2022 > shall be used. > Change the text as follows: > When transferring the contents of a registry entry over a > network, data shall be encoded in the UTF-8 form of ISO/IEC 10646. > Rationale: Given the increasing use of ISO/IEC 10646 as a universal encoding > on the network, it should be designated as the encoding to be used when > transferring the contents of an entry over the network. ISO/IEC 10646-aware > software is much more prevalent than ISO 8824 and ISO/IEC 2022. Not accepted. Other character encodings than UTF-8 needs to be supported. > Annex D Sample Narrative Cultural Specification for Danish and Irish > See Appendix 4 for comments on individual clauses in these examples. > > General comments on Annex D > CD2 TECHNICAL #71 > 1. Confusing title > The title of this annex fails to indicate whether these "samples" of > narrative cultural specifications come from the International Register or > are extracts from applications for registration submitted by Sponsoring > Authorities. This is an important distinction. > The US recommends that the title of this annex indicate the nature of the > content of this annex. > Rationale: > Clarifies the content of the annex. > If the examples are extracts from initial applications, alerts the user to > the fact that the information in the examples will be subject to further > review (as described in clause 7.4) and should not be used in for > implementations. 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. > 2. Defective or outdated information > CD2 TECHNICAL #72 > A number of items in these examples are defective or out-of-date. The US is > concerned that the publication of defective or outdated information in the > examples will reflect badly upon JTC 1 and SC 22. We are also concerned that > implementers might use the information in these examples for software > intended for use in Danish or Irish cultural locales (see preceding related > comment). 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. > 3. Concerns about status of examples > CD2 TECHNICAL #73 > For the proper guidance of users of this standard, examples in this annex > should be actual examples of narrative cultural specifications as submitted > by a Sponsoring Authority after review and approval according to that > Sponsoring Authority's procedures. It is not clear that either example meets > this qualification. > Clause D.1 is entitled "Danish language locale for Denmark, Narrative > Cultural Specification". > There is a published "Danish language locale for Denmark, Narrative Cultural > Specification" (), > but it predates ISO/IEC 15897:1999, the first edition of this standard. > Clause D.1 must therefore show the narrative cultural specification from a > new application (under ISO/IEC 15897) for "Danish language locale for > Denmark". > Different versions of this narrative cultural specification appear in CD1 > and CD2. The CD2 version differs from the CD1 version in a number of items; > for example, discussion of the Greenlandic letter "KRA" has been moved from > CD1 clause 12 to CD2 clause 1. The source statements are: > In CD2 - Source: Dansk Standard, date: 2002-10-08, version: 2.5 > In CD1 - Source: Dansk Standard, date: 1994-07-28, version: 2.4 > It is not clear which version represents the actual narrative cultural > specification submitted by Dansk Standard. (But note that the date of the > CD1 version is earlier than the publication date of the first edition of > this standard.) Not aqccepted. These are examples. They should not need to be actual registrations. It is noted that these examples have updated information compared to existing registrations. > CD2 TECHNICAL #74 > Clause D.2 is entitled "Irish language locale for Ireland, Narrative > Cultural Specification". It is undated. Its version number is given as "0.6 > (Unofficial draft)". > The US recommends that clause D.2 be deleted until the following two > conditions are met: > 1) the content of the narrative cultural specification has been > finalized, that is, it is no longer "draft" > 2) the narrative cultural specification has been officially > approved as correct for Ireland by the National Standards Authority of > Ireland according to its formal procedures. Accepted. > Annexes E and F > * Annex E, "reorder-after" construct in POSIX > LC_COLLATE > * Annex F Information on "reorder-after" > construct in LC_COLLATE) > CD2 TECHNICAL #75 > Remove both Annex E and Annex F. > The US objected to these Annexes in CD1 Objections #39 and #41. > # 39: The reorder-after and reorder-end keywords are > described in ISO/IEC 14651, and should not be repeated here. This annex > should be removed, or rewritten simply to point to ISO/IEC 14651. > # 41: As with Annex E, the reorder-after keyword is > described in ISO/IEC 14651, so information about it is not necessary in this > document. This annex should be removed. > The Editor rejected both comments, stating as his reason: > These specs are also applicable to POSIX locales while 14651 specs are not. > The U.S. continues to object strongly to including these Annexes. The syntax > described already exists in ISO/IEC 14651, and should not be repeated here. > If this syntax is designed to be applicable to POSIX locales, then the > syntax should be in POSIX itself. It is incorrect for this standard to add > normative capabilities to POSIX without the knowledge or consent of those > working on ISO/IEC 9945. > There also are numerous errors in Annex E, but we are not listing them here, > since we believe the entire annex must be removed. Some of the problems with > the content of Annex E were described in CD1 Objection #40 (see the next > comment). Not accepted. These specifications relate also to POSIX locales and not just to 14651. > Clause E.3 Example of "reorder-after" > CD2 TECHNICAL #76 > This extract from N 957 gives the disposition on US Objection #40: > OBJECTION #40 > Section: E.3 (Example of "reorder-after") > Current text: > ". . . > ;; > ;; > ;; > ;; > reorder-end > . . . > 2. The second "reorder-after" statement. . .initiates a second list, > rearranging the order and weights for the , , , , , and > specification. > . . . > 4. Thus for the original sequence > ... > this example reordering gives > ... Uu Vv Ww Xx ( Yy Üü ) Zz ( Ææ Ää ) Øø Åå > 5. . . . > the example reordering in E.3.1 gives > ... ( Uu Ùù Úú ) Vv Ww Xx ( Yy __ Üü ) ( Zz Zz ) > ( Ææ ?Æ?æ ¯Æ¯æ Ää ) ( Øø ?Ø?ø Öö ) ( Åå ( AA Aa aA aa ) ?Å?å )" > Problem and Action: > So much text is quoted because it is completely inconsistent. The example > syntax shows , but not Å and å (). The > explanation in item #2 includes neither the / . The reordering in item #4 shows , but not > /. The reordering in item #5 shows /. > Much of this text is wrong, but it's not clear what the author intended, so > no alternative text is suggested here. Fix the text to be consistent and > correct. > 40. Not accepted. Text will not been changed (for now). > This is unacceptable. US Objection #40 pointed out a serious technical > problem in the content of Annex E. The editor submitted CD2 15897 for ballot > with no changes to the defective text, but implied (via the parenthetical > "for now") that corrections might be made in the future. Any necessary > changes should have been made before CD2 15897 was issued so that all > P-members could review them as part of this ballot. Not accepted. and stands for Å and å respectiviely. There is no defiency. > Annex H Differences from ISO/IEC 15897:1999 and CEN ENV 12005:1996 > H.2 Changes from CEN ENV 12005:1996 > CD2 TECHNICAL #77 > Problem and Action: > The detailed changes listed for this standard as compared to CEN ENV > 12005:1996 all include references to clause numbers from the previous draft, > not this draft. For example, there is the sentence "In clause 4 the contact > information for the Registration Authority has been updated", but in this > CD2, clause 4 contains Terms and Definitions, and contact info is in clause > 7.3. This and all other incorrect references in this section must be > updated. Accepted. > Bibliography > CD2 TECHNICAL #78 > Current text: > 2. ISO/IEC TR 14652:2001 Information technology - > Specification method for cultural conventions. > Problem and Action: > This TR was not published in 2001; it has not yet been published. > ISO/IEC Directives, Part 2: Rules for the structure and drafting of > International Standards specify: > For dated references, each shall be given with its year of publication, or, > in the case of enquiry or final drafts, with a dash together with a footnote > "To be published.", and full title. > The correct publication year needs to be inserted when if it is available. Accepted. > End of Specific Technical Comments > SPECIFIC EDITORIAL COMMENTS > > Foreword > CD2 EDITORIAL #79 > 1) Change "ISO/IEC 9945-2" to "ISO/IEC 9945-1". > Rationale: The reference to ISO/IEC 9945-2 refers to an obsolete edition. > 2) Change "shell and utilities" to "Base Definitions". > Rationale: In the 2002 version of ISO/IEC 9945, POSIX locales and charmaps > are covered in Part 1: Base Definitions. Accepted in principle. See response to US comment 8. > Introduction > CD2 EDITORIAL #80 > Second paragraph, second sentence: > Change "network" to "Internet" > Rationale: "network" is a generic term and could refer to any network. The > correct term is "Internet". > JTC 1 practice appears to be to capitalize "Internet" (as in Annex HF > Glossary of Terms in Procedures for the technical work of ISO/IEC JTC 1). Accepted. > CD2 EDITORIAL #81 > Second paragraph, second sentence > Change "eg" to "for example," > Rationale: Better style for an introduction. > Erroneous forms of the abbreviation "e.g." occur throughout the text. They > should all be corrected or changed to "for example". (Both alternatives are > used in ISO and JTC 1 documentation.) Accepted. > 4 Terms and definitions > CD2 EDITORIAL #82 > Arrangement > In N 945R, the terms were arranged in alphabetical order. Alphabetical order > was not used for the Terms and definitions in CD2. The Editor explained (in > e-mail) that this was not done because translations must be identical. When > alphabetical order is used, there could be problems with a translation. If > the order of the source was retained, some terms might be out of > alphabetical order in the translation. On the other hand, if the translated > terms were ordered according to the alphabetical order of the language of > translation, the order of terms might be different in the source and the > translation. > It is difficult to see any order in the current text, except that locale is > superior to all other terms. > The specific requirement in the ISO/IEC Directives, Part 2 is: > 4.5 Equivalence of official language versions > The texts in the different official language versions shall be technically > equivalent and structurally identical. The use of bilingualism from the > initial stage of drafting is of great assistance in the preparation of clear > and unambiguous texts. > There is no stated requirement for the order of the Terms and definitions > clause in a document. The order of an independent terminology standard > "should be preferably classified." (clause 6.2.1). However, this clause > continues: > Lists of equivalent terms in different languages may be presented either in > systematic order as indicated above (in which case alphabetical indexes > shall be given for each of the languages), or in alphabetical order of the > terms in the first of the languages used (in which case alphabetical indexes > shall be given for each of the other languages). > Note that in Annex E: Registration Definitions and Guidelines for Procedure > Standards in Procedures for the technical work of ISO/IEC JTC 1, the > elements in clause E.1 Definitions are ordered alphabetically. > This revised standard is being developed in English. In a translation, the > number assigned to each term must be retained to meet the "structurally > identical" requirement of clause 4.5 of the ISO/IEC Directives. Variations > from the alphabetic order of the language of translation should be explained > in a Note, for example: > NOTE: The order of the terms corresponds to their order in > the original English language version of this standard. > Draft note for the French translation: > NOTE: L'ordre des termes correspond à leur ordre dans la > version originale d'anglais de cette norme. > Draft note for the Russian translation: > ??????????: ??????? ???????? ????????????? ?? ??????? ? > ???????????? ?????? ????? ????????? ?? ?????????? ?????. Not accepted. ISO 2382 does it this way. > 4.7 narrative cultural specification > CD2 EDITORIAL #83 > The definition for "narrative cultural specification" was modified in > response to CD1 Objection #9. The definition now reads: > A narrative description of culturally dependent information pertaining to > software use on computers. Such information may be useful when designing > computer systems and software. See clause 9.3.2 and 9.4. > Delete the phrase "pertaining to software use on computers". > Rationale: > (a) It could be misunderstood as limiting the information only > to information about ("pertaining to") the use of software on computers. > (b) It essentially repeats what the second sentence says better. Accepted in principle It is changed to "pertaining to Information Technology". > 5.4.1 Structure of the identifier > CD2 EDITORIAL #84 > Change the title of this clause to: > Structure of the identifiers > Note that "identifiers" should not be capitalized. > Rationale: There are two types of identifiers for registrations. Accepted. > 5.4.2 Reference to an approved registration > CD2 EDITORIAL #85 > The final sentence is: > Examples are listed in clause 9.3.8. > These are examples of token identifiers. At least one example of a > registration number must be given as well (either as an example here, or by > means of a reference to the place where the example appears.) Accepted. > 5.5 No modification nor deletion of registrations > CD2 EDITORIAL #86 > Current text: > The contents of an individual registration shall never be changed or deleted > once it has been registered (except for name additions)... > Change "it has been registered" to "the application for registration has > been approved". > Rationale: > Incorrect grammar (plural/singular mismatch) > The point at which further changes are prohibited is when the application is > approved. The rewording makes this clear. Accepted. > 7.3 Identity > CD2 EDITORIAL #87 > Change the URL for Maintenance agencies and registration authorities from > http://www.iso.ch/mara > to > http://www.iso.org/mara > Change the URL for Autorités de mise à jour et organismes d'enregistrement, > from > http://www.iso.ch/mara-fr > to > http://www.iso.org/mara-fr > Rationale: Although either URL works, ISO appears to prefer ".org" to ".ch". Accepted. > 7.4 Registration Procedure > Item h > CD2 EDITORIAL #88 > Current text: > "to inform the appropriate Sponsoring Authority when a application does not > comply to the rules." > Problem and Action: > Grammar; "...comply with the rules;" Accepted. > Item f > CD2 EDITORIAL #89 > The current text is identical to the text in the CD1 except that one change > -- "proposal" to "application"- has been made: > to assign to the Cultural Specification appropriate token identifiers based > on the information given by the Sponsoring Authority, and to assign to the > Cultural Specification the next available number to be used as a numeric > identifier when the application complies with the rules, unless the Cultural > Specification is identical to one already registered, in which case the new > token identifiers shall be added to the existing registration; > Split this excessively complex item into a new paragraph with two parts > worded as follows: > Following approval of an application for registration, the Registration > Authority shall: > a) to assign to the a new Cultural Specification appropriate token > identifiers based on the information given by the Sponsoring Authority, and > to assign to the Cultural Specification the next available number to be used > as a numeric identifier ; > b) If the Cultural Specification is identical to one already registered, the > new token identifiers shall be added to the existing registration, and the > addition shall be noted in the version history of that registration; > Rationale: Reduction of complexity. > Note that "when the proposal complies with the rules" has been replaced by > "Following approval of an application for registration" (which occurs > because "the proposal complies with the rules"). Not accepted. The new wording is inconsistent, as it first assigns a new number and then retains the old number. > Item i > CD2 EDITORIAL #90 > In the title of this clause, change "Procedure" to "procedure". Accepted. > 8.1 Identity [of the Sponsoring Authority] > CD2 EDITORIAL #91 > Second paragraph: > Sponsoring Authorities may submit applications for registration of the types > Charmaps and Repertoiremaps to support their other Cultural Specifications. > Move this paragraph to Clause 8.2 Responsibilities, and insert it > immediately after item (d). > Rationale: This paragraph describes an action that the Sponsoring Authority > may perform. It does not belong in a clause defining the Sponsoring > Authority itself. Accepted. > CD2 EDITORIAL #92 > Third paragraph: > Current text of this paragraph: > The RA shall reject applications for registrations which come from sources > other than Sponsoring Authorities, or applications from Sponsoring > Authorities that they do not have the authority to register. The RA may > refer the applicant (eg. a firm or an organization) to an appropiate > Sponsoring Authority, if one can be identified. > Make the changes specified below to the text of this paragraph and move the > modified text to the end of the clause dealing with Registration procedures. > Rationale for moving the paragraph: This paragraph describes actions carried > out by the Registration Authority. It has nothing to do with the definition > of the Sponsoring Authority. It is in the wrong place. > 1) Change "RA" to "Registration Authority" (two occurrences). > Rationale: For consistency with "Sponsoring Authority/Authorities" in this > paragraph. > 2) Change the phrase "other than Sponsoring Authorities" to > "other than the Sponsoring Authorities as defined in clause 8.1." > Rationale: Current text lacks precision. > 3) Delete the following text > or applications from Sponsoring Authorities that they do not > have the authority to register. > Rationale: > (a) To what does "they" refer? > (b) "they" must mean "Sponsoring Authorities" > (if "they" is interpreted as "the Registration Authority", the text makes no > sense). But registration is done by the Registration Authority, not by > Sponsoring Authorities. > (c) A submitter of an application that does not > fall into one of the categories defined in clause 8.1 is NOT a "Sponsoring > Authority," merely a sponsor or a submitter. > 4) Change "eg" to "for example," > 5) Change the first comma after the first occurrence of > "Sponsoring Authorities" to a full stop (because the remainder of the > sentence has been deleted). Accepted in principle. "to register" will be changed to "propose for registration". > 8.2 Responsibilities > CD2 EDITORIAL #93 > Change "eg." to "for example," Accepted. > CD2 EDITORIAL #94 > Item b > Change "an application" to "applications". > Rationale: For consistency with other items, where the plural form > "applications" is used. Accepted. > CD2 EDITORIAL #95 > Item e > Replace item e > to forward to the Registration Authority those applications that have their > support; > with the following text: > to submit applications for the registration of Cultural > Specifications to the Registration Authority; > Rationale: > (a) "that have their support" is redundant. A Sponsoring > Authority would not submit an application that did not have its approval. > (b) "their" --> "its" ("a Sponsoring Authority" is singular) Accepted. > CD2 EDITORIAL #96 > Item f > Change this text: > their respective countries or organizations. > to > its respective country, region, or organizations. > Rationale: Grammar -- to agree with the implied "Sponsoring Authority" which > is singular. > Note: It is OK to drop "countries" from item f since Sponsoring Authorities > for this standard will not have jurisdiction for multiple countries. (CEN > has jurisdiction for Europe as a whole.) Accepted. > # The Joint Advisory Committee for ISO/IEC 15897 > CD2 EDITORIAL #97 > Carry out the textual changes specified for clause 11 and then relocate the > whole clause (including its heading) immediately after clause 8 Sponsoring > Authority. > Rationale: The definition of the Joint Advisory Committee must be grouped > with the definitions of all other functional agencies applicable to this > standard. > Currently, in CD2 15897, the abbreviation "RA-JAC" is used in clause 10, but > (a) the abbreviation is not explained, and (b) the Joint Advisory Committee > is not defined until the following clause (11). This is a serious editorial > defect that the Editor failed to correct for CD2 15897. Accepted. > Clause 9.1 Types of cultural Specifications > CD2 EDITORIAL #98 > Capitalize "cultural" in the title of this clause. > Explanation: Although the title of a clause is normally all lowercase except > for the first letter, "Cultural Specification" is treated as a proper noun > (with capitals) in this standard. Accepted. > Clause 9.2 Relations between registration types > Clause 9.2.1, first sentence: > CD2 EDITORIAL #99 > In clause 9.2.1, in the phrase "any of the official ISO languages: English, > French, or Russian," change "ISO" to "ISO/IEC JTC 1". > Rationale: The Procedures for the technical work of ISO/IEC JTC 1 is the > applicable authority. This is the relevant text from the Procedures: > 7.9.1 The languages of JTC 1 are English, French and Russian. In general, > the work of JTC 1 and its subsidiary bodies may be in any one or more of the > above-mentioned languages. However, meetings are conducted in any one of > these. The Chairman or Convener is entitled to authorize participants to > speak in a language other than that in which the meeting is conducted. The > NB for the Russian Federation provides all interpretation and translation > into or from the Russian language into or from another official language. Accepted. > Clause 9.3 Rules for Cultural Specifications > Clause 9.3.5 > CD2 EDITORIAL #100 > Current text: > The sources shall be delivered electronically, either via > electronic mail or on a diskette, to the Registration Authority. > Reword as: > either via electronic mail or on physical storage media > Rationale: Current wording is too restrictive and backward looking. Accepted. > Clause 9.3.7 > CD2 EDITORIAL #101 > Change "all" to "All" > Rationale: Orthographic conventions. Accepted. > Clause 9.3.8 > CD2 EDITORIAL #102 > Current text of the 6th paragraph (between the two Notes) ends: > ... thus giving preference specifications from National Standardization > Organizations. > Insert "to" between "preference" and "specifications" > Rationale: Grammar. Accepted. > Clause 9.4 Contents of a Narrative Cultural Specification > CD2 EDITORIAL #103 > Wherever possible in the text describing the individual clauses, change the > passive "Here ... is described" construction to "This clause describes ..." > (or "This clause includes ..." when only some of the contents of the clause > are mentioned). Accepted. > Clause 1: Alphanumeric deterministic ordering > CD2 EDITORIAL #104 > Current text: > Issues to cover may be: are there any letters that are > sorted differently from other languages, are capital letters sorted before > small letters, are there a specific ordering of accents, in which order > should different scripts be, do some characters sort equally at first and > then when the whole string is otherwise consider red equal, should they then > be sorted differently at other levels? > Rewrite as: > Issues to cover may include whether there are letters that > sort differently from common use in other languages, whether capital letters > sort before small letters, or whether there is a specific ordering of > diacritics. Further, this section may describe the ordering of scripts, and > sorting levels -- that is, if there are cases when characters sort equally > at first, but then may sort differently at other levels. > Rationale: Grammar. Accepted. > CD 2 EDITORIAL #105 > The title of this clause is inappropriate because its content may cover > scripts that are not alphabets. New name should be: > Ordering of textual data Partially accepted. Text will be added to clarify that this can also address non-alphabetic scripts. > Clauses 7 through 32 > See Appendix Four for US technical and editorial comments on the optional > (non-POSIX) clauses. Noted. > 10 Appeal procedures > CD2 EDITORIAL #106 > Delete the first line of text: > Appeal against the decision of the Registration Authority can be made as > follows: > Rationale: Redundant. The title of the clause says the same thing more > succinctly. Not accepted. The text is introductory, and does not harm. > Clause 11.2 > First paragraph > CD2 EDITORIAL #107 > Spelling of "subcommittee' still has to be corrected by inserting "t". accepted. > Annex A Application form for a Cultural Specification > Introductory paragraph > CD2 EDITORIAL #108 > Current text: > Please specify all data relevant for the Cultural Specification type, > indicating non-available data by "not available"... > Reword as: > Please specify all data relevant for the Cultural Specification type, or > enter "not applicable"... > Rationale: Clarity. accepted. > Annex D Sample Narrative Cultural Specification for Danish and Irish > CD2 EDITORIAL #109 > Change title of Annex D to: > Examples of Narrative Cultural Specifications > Rationale: > (a) These are "examples", not "samples". (For examples of use, > see Annex B and Annex G in ISO/IEC Directives, Part 3 Rules for the > structure and drafting of International Standards) > (b) The examples are intended to show the content of narrative > cultural specifications, without emphasis on language. accepted. > Annex H Differences from ISO/IEC 15897:1999 and CEN ENV 12005:1996 > H.1 Changes from ISO/IEC 15897:1999 > CD2 EDITORIAL #110 > Current text: > 3. The text was revised to align with wordings of the new ISO/IEC 2375 > International Standard, which the original wordings in the CEN ENV 12005 was > build from. > Reword as: > 3. The text was revised to align with ISO/IEC 2375. > Rationale: > (a) Grammar ("wording" is singular; "was built" not "was build") > (b) Removal of text that applies to the 1999 version of this > standard. Accepted in principle, but the history will be retained. > CD2 EDITORIAL #111 > Current text: > 7. Some parts of the text was moved around, eg annex G which is now clause > 9.4. > Reword as: > 7. Some parts of the text were moved around. For example, the former Annex G > is now clause 9.4. > Rationale: Grammar. Accepted. > End of Specific Editorial Comments > APPENDIX 1 > US comments on specific aspects of the text of clause 7.4 > > The US recommends (see Technical Comments) that clause 7.4 be replaced by > two more detailed clauses. The comments in this appendix identify problems > with the text of clause 7.4 as it exists. > Item c > CD2 TECHNICAL #112 > Current text: > to circulate applications to ISO/IEC JTC1/SC22 members, liaisons and the > Registration Authority's Joint Advisory Group,... > Insert a reference identifying the clause where the Registration Authority's > Joint Advisory Group is described in detail immediately after "Group". > Rationale: The RA-JAC has not yet been defined. Accepted. > CD2 TECHNICAL #113 > The text of item c, clause 4 Registration Authority of the CD1 reads: > in the case of a POSIX Locale, to ascertain that the POSIX > Locale and the corresponding Narrative Cultural Specification are not in > contradiction > In CD1 Objection #12, the US asked: > What if the two do contradict each other? Suppose there is a > "foo" POSIX locale definition, and a "foo" narrative cultural spec. Suppose > the cultural spec includes does not include it in the Is one rejected, or asked to be revised? What if the locale was registered a > few years ago, and changing attitudes now make the fact that included obsolete? To give a concrete example, locales from the early 1990s > often include a limited repertoire of characters -- Western European ones > may only include a subset of ISO 8859-1 characters. Locales (or cultural > specifications) written now often take a broader definition of what should > be included. Under this clause, is one of these wrong? What must be done? > Should the older one be marked obsolete? What about users who depend on it? > The existing text is incomplete and vague about the > Registration Authority should do if a contradiction exists. More information > must be added - once decisions about what happens have been made. > In the DoC, the Editor responded: > 12. Noted. There will always be errors. The RA should > probably send an application back if it sees errors, and the SA would then > have a chance to correct and then resubmit. The RA should then register, and > probably come forward with comments. The RAC could also make comments. N > 945R is addressing this, and text will be added to clarify it. > In the CD2, the responsibility for resolving inconsistencies between a POSIX > Locale and the corresponding Narrative Cultural Specification appears to > have now been assigned entirely to the Sponsoring Authority (clause 8.2 > Responsibilities [of a Sponsoring Authority], item c). > in the case of a POSIX Locale, to ascertain that the POSIX > Locale and the corresponding Narrative Cultural Specification are not in > contradiction; Noted. > Item d > CD2 TECHNICAL #114 > Current text: > to forward the comments received to the Sponsoring Authority > for possible integration in the final documents; > Problem and Action: > >From this text, it sounds as if the RA is merely a clearinghouse for > comments; that it makes no judgments on the contents of proposals or on > comments that others make. Is that the case? It seems more appropriate for > the RA to be the body that debates the contents and decides whether they are > acceptable. Otherwise, it appears that the SA has all the power to decide > what a proposal will contain, as well as power to dispose of any comments > received. > This problem is addressed in the first of the two clauses that the US > proposes as replacements for clause 7.4. In particular, following technical > review by the RA-JAC, > x.7 The Registration Authority shall inform the Sponsoring > Authority of any changes needed to satisfy the concerns of the RA-JAC. > and, following review by the P-members of SC22, > x.9 The Registration Authority shall consider all comments > received. The Registration Authority shall request the RA-JAC to provide > expert advice on the technical comments. The Registration Authority may > incorporate comments resulting from the review specified in clause > into the final registration. 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. > Item e > CD2 TECHNICAL #115 > Current text: > in the case of comments, to optionally receive from the > Sponsoring Authority revised applications addressing the comments received; > Substitute this text for the current text: > to receive revised applications from the Sponsoring > Authority that address comments made about the application by reviewers, and > to decide whether the revisions are acceptable; > Rationale: > 1) There is no way to "optionally receive" something. Shouldn't > this say "...optionally accept"? > 2) The "optionally" is perhaps intended to convey the fact that > not every application will need to be revised in response to comments. > 3) "in the case of comments" is redundant. Partially accepted. Wording will be changed, but the RA will have no say about whether the changes are acceptable. > End of Appendix 1 > APPENDIX 2 > Rearrangement of Clause 9 Rules for Applications > > To facilitate the use of ISO/IEC 15897, the US proposes that clause 9 be > reorganized into six separate clauses dealing with these topics: > 1. Types and relationships of cultural specifications; > 2. Contents of a narrative cultural specification; > 3. Use of character names; > 4. Requirements for applications; > 5. Format of registration documents; > 6. Specification of the token identifier; > > In the rearrangement, an ordinal number enclosed in square brackets (for > example, "[1st]") represents the number of a main clause. Subclauses are > numbered in the usual way. > The text is almost entirely taken from clause 9 of N 987. Text from N 987 > has been copied "as is," which means that typographical or grammatical > errors have not been corrected. Clause numbering from N 987 is included as > an aid to reviewers. > The very few pieces of text that were inserted or deleted for stylistic > reasons are shown by underline or strikethrough respectively. US > recommendations for changes to the text itself have NOT been applied here, > so that reviewers can focus entirely on how this clause ought to be > restructured. > > [1st]. TYPES AND RELATIONSHIPS OF CULTURAL SPECIFICATIONS > [1st].1 Types of cultural specifications = 9.1 Types of cultural > Specifications > A number of types of Cultural Specifications can be registered according to > this International Standard: > 1. Narrative Cultural Specification > 2. POSIX Locale > 3. POSIX Charmap > 4. POSIX Repertoiremap > 5. Machine-parsable cultural specification > 6. Machine-parsable coded character set specification > > Type 1 are for Narrative Cultural Specifications, further specified in > clause 9.3.2. > Types 2 and 3 are for POSIX specification of cultural conventions defined in > ISO/IEC 9945-2. > Type 4 is for Repertoiremaps defined in this International Standard (clause > 9.3.9) and in ISO/IEC TR 14652. > Types 5 and 6 are for specification of cultural conventions in a > machine-parsable format, such as specified in ISO/IEC TR 14652, XML or SGML > table formats. Any format is allowed as long as it is machine parsable and > adheres to the following rules: It is a TR 14652 FDCC-set, a TR 14652 > charmap, or the first line of the file identifies the file format. > [1st].2 Relations between registration types = 9.2 Relations between > registration types > The relation between the types is the following: > Registration types are related as follows: > [1st].2.1 Narrative Cultural Specification > 9.2.1. The Narrative Cultural Specification specify cultural conventions in > narrative form in any of the official ISO languages English, French and/or > Russian, and it may give equivalent specifications in other languages. It > may thus address issues which have not yet been codified by formal methods > for specifications of cultural conventions. If parts of a Narrative Cultural > Specification has been specified also in POSIX Locale or Charmap format, > this Locale or Charmap should be referenced in the specification. > [1st].2.2 POSIX Locale > 9.2.2. The POSIX Locale shall specify appropiate aspects of a Narrative > Cultural Specification in formal POSIX syntax. The POSIX Locale shall refer > to the Repertoiremap being used, and should also list a number of POSIX > Charmaps that it can use. > 9.3.3 (part) The POSIX Locale shall define all standard categories (for > example by copying categories of a standard POSIX Locale; examples are given > in annex F). > 9.4 (part) If a POSIX locale is submitted, it is desirable that it be > accompanied by a related narrative cultural specification. > [1st].2.3 POSIX Charmap > 9.2.3. The POSIX Charmap shall specify aspects of a Narrative Cultural > Specification or a POSIX Locale that relate to coded character sets. A POSIX > Charmap shall refer to the Repertoiremap being used, but need not refer to > the POSIX Locales nor the Narrative Cultural Specifications using it. > [1st].2.4 Repertoiremap > 9.2.4. The Repertoiremap is used as a tool to enable a POSIX Locale or a > Narrative Cultural Specification to be independent of coded character sets, > and to remove the requirement for POSIX Charmaps when registering a POSIX > locale. It need not refer to other Cultural Specifications. > [1st].2.5 Other specifications > 9.2.5. In the case of a TR 14652 FDCC-set, or other machine-parsable > cultural specification, it shall specify in formal syntax some aspects of a > Narrative Cultural Specification, and shall refer to a corresponding > Narrative Cultural Specification. In case of a TR 14652 FDCC-set it shall > refer to the Repertoiremap being used, and should also list a number of > Charmaps that can be used. > 9.3.3 (part)The FDCC-set shall define all standard categories (for example > by copying categories of a standard "i18n" FDCC-set; examples are given in > annex F). > 9.2.6. In case of a ISO/IEC TR 14652 Charmap, or other machine-parsable > character set descriptions it shall specify aspects of a Narrative Cultural > Specification or an FDCC-set that relate to coded character sets. In case of > a Charmap it shall refer to the Repertoiremap being used, but need not refer > to the FDCC-set nor the Narrative Cultural Specifications using it. > NOTE: It is the intention to allow more formal specification > methods in future revisions of this International Standard when they become > standardized methods; for the time being these specifications can be > registered as type 1, 5 or 6. > [2nd]. CONTENTS OF A NARRATIVE CULTURAL SPECIFICATION > = 9.4 Contents of a Narrative Cultural Specification > The contents of the Narrative Cultural Specification is described in some > detail in the following. it builds on information from the POSIX Shell and > Utilities standard (ISO/IEC 9945-2) and the Nordic Cultural Requirements on > Information Technology Summary Report. > Clause 7 to 32 are to provide information, which is not presently > expressible in POSIX notation. Examples of Narrative Cultural Specifications > are given in annex D. > [2nd].1 Mandatory Clauses > 9.3.2 The format of a Narrative Cultural Specification shall contain the > clauses (numbered 1-6) specified below. 9.4 These clauses are POSIX > categories. The Narrative Cultural Specification should be accompanied by a > corresponding POSIX Locale specification. 9.3.2 The information given in > these clauses of the Narrative Cultural Specification may also be described > in an FDCC-set, or other machine parsable cultural specification: > Clause 1: Alphanumeric deterministic ordering > Here the specification of a national standard for ordering should be listed. > If there are more standards, or options for a standard, there should be one > POSIX specification for each of the standards or options. A European > Multilingual Sorting standard, or other international standards, already in > this registry, could be referenced and possible deviations, if any, could be > described. Issues to cover may be: are there any letters that are sorted > differently from other languages, are capital letters sorted before small > letters, are there a specific ordering of accents, in which order should > different scripts be, do some characters sort equally at first and then when > the whole string is otherwise considerered equal, should they then be sorted > differently at other levels? Does the language require reordering of some > characters before collation weighting (e.g. Thai)? Does the language sort on > a syllabic basis, rather than merely letter-by-letter (e.g. Burmese)? Does > the language make use of ideographs, and if so, how are they handled with > respect to other characters? If aspects of the ordering for the language > extend beyond what a POSIX specification can handle, then details can be > described in Clause 10. > Clause 2: Classification of characters > The POSIX standard allows descriptions of what is alphabetic characters, > capital and small letters, digits, hexadecimal digits, punctuation > characters, spaces, graphical characters and control characters. > Clause 3: Numeric formatting > Here it is described how numbers are keyed in and formatted, including the > format of the decimal point and the thousands separator. > Clause 4: Monetary formatting > Here formatting rules for monetary amounts, as well as local and > international currency symbols according to ISO 4217, are described, as well > as the relation between the amount, a sign and the currency symbol. > Clause 5: Date and time conventions > Various names for days and months are given, together with formats for > writing date and time. Things to consider are: do day and month names start > with a capital letter or a small letter? Are there well recognized > abbreviations for the day and month names? Is ISO 8601 formatting > widespread? As the date formats are for use in POSIX, for example when > listing files, consideration should be given to possible POSIX conventions > in the culture. > Clause 6: Affirmative and negative answers > Here the short notation for "yes" and "no" answers in the language can be > specified. If the culture has strong relations to several languages, for > example in a multilingual country, it should be permitted to answer in any > of the languages. As English is widely used in many cultures, allowing > responses in the English language should be considered. > [2nd].2 Optional Clauses > 9.3.2 (remainder) The Narrative Cultural Specification may also include > other culturally dependent information, specified in clauses 7-32. 9.4 These > clauses are not directly related to POSIX Locales: > NOTE: Further information about the categories, along with > specific examples illustrating their use may be found in clause 9.4 and in > the Nordic Cultural Requirements on Information Technology (Summary Report). > Clause 7: National or cultural Information Technology terminology > Here terminology for a language or culture can be listed, for example a > translation of ISO terminology for Information Technologies. > Clause 8: National or cultural profiles of standards > Here profiles of standards can be listed, for example, OSI national > profiles, or profiles of the POSIX standards. See the POSIX ISO/IEC 9945-2 > standard for an example. > Clause 9: Character set considerations > Here it can be described how characters are used in the culture, for > example: > - which characters are necessary to write a particular language, > - which characters are used to give further precision in the language, > - which characters are usually used in newspapers and books for writing of > names and places, > - which characters are used for historic writing of the language, > - and which characters are used for other purposes. > This clause may also be used to specify which coded character sets are > common in the culture and what coded character sets are recommended. Also > further descriptions of coded character sets may be described; it is also > possible to document these in the form of a POSIX Charmap registration. > 9.3.2 (part) In clause 9 it is possible to give further information on > characters classified in clause 2 (mandatory). > Clause 10: Sorting and searching rules > This is much like clause 1, but can be used for further descriptions, such > as how to split a record into sorting fields, and special words which are > ignored when comparing or searching. Also sound based matching rules may be > described here. What can be accomplished with POSIX should be described in > clause 1. > Clause 11: Transformation of characters > Here transliterations and transformations of characters can be described, > for example transliteration rules between Latin, Greek and Cyrillic, or > fallback notation for some frequent letters. Also this is the place to write > about standards in the culture for character conversion. > Clause 12: Character properties > Here additional considerations further than those given in clause 2 can be > given, for example how small letters without a direct capital counterpart > may be capitalized, or special capitalization rules. > 9.3.2 (part) Clause 12 is for description of cultural aspects in excess of > what can be described in the corresponding POSIX clause 2. > Clause 13: Use of special characters > Here use of special characters, such as quotation marks, abbreviation marks, > and punctuation marks can be described. Also interesting here may be what to > avoid, for example number signs, pilcrow sign and division signs are not > used in documents in several cultures. Spacing rules and the relation > between different punctuation signs is also relevant here. > Clause 14: Character rendition > Special considerations about rendition such as what alternatives may be > considered adequate, and acceptable glyphs, may be described in this clause. > Clause 15: Character inputting > A keyboard seldom has separate keys for all the characters needed. This > clause is intended for description of keyboard inputting rules and other > input methods. > Clause 16: Personal names rules > Personal naming differs from culture to culture, for example what is > considered the family name, how titles are used, are family names spelt > thruout in capital letters, and whether given names or initial are used. > Also the rules for children inheriting their fathers' and mothers' family > name, and what happens for married couples may bedescribed here. > Clause 17: Inflection > Languages vary much with respect to inflection, different forms of words > depending of the context. here the rules can be described or referenced. > Some common translation APIs today take some aspects of this into account, > eg. the UNIX gettext() functions deal with singular/plural forms of nouns. > Clause 18: Hyphenation > Hyphenation rules can be described here, and also references to the > specifications for a language may be done here. > Clause 19: Spelling > This clause is for specification of spelling rules and spelling lists, or > reference to orthographic documentation. > Clause 20: Numbering, ordinals and measuring systems > Here measurement systems can be described (normally this is the ISO SI > system). Use of decimal points and thousands separator should be described > in clause 3. > 9.3.2 (part) Clause 20 is for description of cultural aspects in excess of > what can be described in the corresponding POSIX clause 3. > Clause 21: Monetary amounts > Here further considerations to clause 4 can be described, such as old > currencies. > 9.3.2 (part) Clause 21 is for description of cultural aspects in excess of > what can be described in the corresponding POSIX clause 4. > Clause 22: Date and time > This is for considerations in excess of clause 5, such as non-POSIX date > conventions, time zone names and daylight savings rules, and other written > expressions like "half seven" - what is then really meant - 06:30 as in > Germany or Denmark, or 07:30 as in Britain? > 9.3.2 (part) Clause 22 is for description of cultural aspects in excess of > what can be described in the corresponding POSIX clause 5. > Clause 23: Coding of national entities > Here coding for different entities can be described, such as postal codes, > administrative codes for local government, police districts, abbreviations > for cities or provinces, and time zone names relating to different parts of > the culture. > Also specifications should be given for identification of the whole culture, > for example ISO country codes for a nation. > Clause 24: Telephone numbers > The formatting of telephone numbers, nationally and internationally. > Clause 25: Mail addresses > The formatting of postal addresses, where to put the title of the addressee, > the street number and the postal code, what are the names of the storeys, > and other conventions used. > Clause 26: Identification of persons and organizations > A culture may have numbering schemes for persons and organizations, for > example social security numbers, and general tax numbers for companies, > together with registries for different organisation forms such as limited > companies and associations. This clause may be used to describe such > numbering systems. > Clause 27: Electronic mail addresses > Cultural conventions for Internet and X.400 electronic addresses etc. may be > described here. > Clause 28: Payment account numbers > Cultural conventions for bank account numbers can be described here. > Clause 29: Keyboard layout > Here the conventions for keyboard layout may be described. > Clause 30: Man-machine dialogue > Considerations for how to localize products may be described here. > 9.3.2 (part) Clause 30 is for description of cultural aspects in excess of > what can be described in the corresponding POSIX clause 6. > Clause 31: Paper formats > Here it can be described what the conventions are for paper size (normally > ISO standards) and the use of window envelopes, etc. Also how punched holes > are placed in paper may be relevant here. > Clause 32: Typographical conventions > This clause may be used for how layout is done, for example how to layout a > business letter, or a fax. Use of special characters, for example quotation > marks, should be described in clause 13. > [2nd].3 Limitations on Character Content > 9.3.7 (part) The information in items 8 to 14 is used in the token > identifier for the Cultural Specifications. > Items 8 to 13 may contain digits 0123456789 and the characters uppercase and > lowercase forms of > ABCDEFGHIJKLMNOPQRSTUVWXYZ > Item 10 may also contain the special characters: > /()*-.:_ > Note: all of these characters are included in ISO/IEC 10646-1 U0020..U007E. > Case of letters is not significant in token identifiers. > > [3rd]. USE OF CHARACTER NAMES > 9.3.9 POSIX Locale, FDCC-set and Charmap sources shall be specified in a way > that is independent of coded character sets, using character names. Relation > between the character names and characters shall be specified via a > Repertoiremap table, giving the character name and the ISO/IEC 10646 short > character ID in the form of Uxxxx or Uxxxxxxxx, and optionally the long > ISO/IEC 10646 character name. It is recommended to use, whenever possible, > character names specified in ISO/IEC 9945-2:1993 Annex G. The character name > and the ISO/IEC 10646 canonical encoding are each surrounded by angle > brackets <>, and the fields shall be separated by one or more spaces or tabs > on a line. If a right angle bracket or an escape character is used within a > name, it shall be preceded by the escape character. The escape character can > be redefined from the default reverse solidus (\) with the first line of the > Repertoiremap containing the string "escape_char" followed by one or more > spaces or tabs and then the escape character. > > [4th]. REQUIREMENTS FOR APPLICATIONS > 9.3.6 A written application shall accompany the Cultural Specification and > be signed by authorized personnel on behalf of the contributing > organization. It shall release copyrights of the contributed sources. > 9.3.7 (part) Annex A specifies a form to be filled out for each Cultural > Specification; Annex B gives an example of a completed form. > 9.3.7 (part) If any of the above information specified below is > non-existent, it must be stated in each case; the corresponding string is > then the empty string. The default case in 11 and 12 is also represented by > an empty string. If required information is not present in any of the ISO > 639 parts or ISO 3166, the relevant Maintenance Authority shall be > approached by the Sponsoring Authority to get the needed item registered. > [4th].1 Required for All Applications > 9.3.7 The written Cultural Specification application shall contain > information on the following items: > 1. Cultural Specification type number (as in 9.1 above) > 2. Organization name of Sponsoring Authority > 3. Organization postal address > 4. Name of contact person > 5. Electronic mail address of the organization, or contact person > 6. Telephone number for the organization, in international format. > 7. Fax number for the organization, in international format. > All applications shall contain information on these items: > 11. If not for general use, an indication of the intended user audience. The > Registration Authority decides on a corresponding identifier element, to be > used in the token identifier for the specification. > 12. If for use of a special application, a description of the application. > The Registration Authority decides on a corresponding identifier element, to > be used in the token identifier for the specification. > 13. Short name for Sponsoring Authority, for possible use in the token > identifier. Blank if this is from a National Standardization Organization. > 14. Revision number consisting of digits and zero or more full stops ("."). > 15. Revision date in the format according to this example: "1995-02-05" > meaning the 5th of February, 1995. > [4th].2 Required for Types 1, 2 and 5 > 9.3.7 (part) For Types 1, 2, and 5, Narrative Cultural Specifications, POSIX > Locales, and FDCCsets and other formal descriptions of cultural conventions: > 8. Natural language, as specified in ISO 639-1, or ISO 639-2 terminology > codes if an ISO 639-1 code does not exist. > 9. Territory, as two-letter form of ISO 3166 > [4th].3 Required for Types 3, 4, and 6 > 9.3.7 (part) For Types 3, 4, and 6, POSIX Charmaps, Repertoiremaps, and TR > 14652 Charmaps and other formal descriptions of character sets: > 10. Suggested Charmap or Repertoiremap or other name > > [5th]. FORMAT OF REGISTRATION DOCUMENTS > [5th].1 General > 9.3.1 A application for registration of a Cultural Specification shall be > submitted as a Text File. A Narrative Cultural Specification may > alternatively be submitted on white paper of the approximate size 297 by 210 > mm, with margins of no less than 20 mm, or one of the approved document > formats of ISO/IEC JTC 1, as noted in JTC 1 directives. > 9.3.5 The sources shall be delivered electronically, either via electronic > mail or on a diskette to the Registration Authority. Narrative Cultural > Specifications may alternately be delivered on paper. > 9.3.4 The coded character set of ISO/IEC 646 International Reference Version > (ISO 2375 registration number 6) shall be used to represent text for the > submitted files. For enhanced network portability it is recommended that > only the invariant part of ISO/IEC 646 (ISO 2375 registration number 170), > which contains 83 graphical characters (including space), be used. Comments > shall be given in the English language, and equivalent comments may also be > given in other languages. If characters outside ISO/IEC 646 International > Reference Version are needed, character names defined in a Repertoiremap > shall be used. > [5th].2 Narrative Cultural Specification > 9.3.2 (part) Each clause shall begin on a new line after at least one blank > line, and each clause shall be introduced by the string "Clause ", followed > by the decimal clause number for the issue as listed above, then a colon and > a space, and then the title of the clause, using the titles above (examples > are given in annex D). > 9.3.2 (part) The body of the clause shall follow on the succeeding lines. A > reference to a clause within the specification shall consist of the string > "=> Clause " followed by the clause number. A reference to another > specification shall consist of the string "=> Spec. "followed by the > registration number of the specification and, optionally, the string "Clause > " and a clause number. > [5th].3POSIX Locale and Charmap > 9.3.2 (part) The format of the POSIX Locale and Charmap sources shall be > conformant to ISO/IEC 9945-2, or for POSIX Locales the technique specified > in Annex E. > [5th].4 Repertoiremap > 9.3.2 (part) The format of the Repertoiremap shall be conformant to clause > 9.3.9. > > [6th]. SPECIFICATION OF THE TOKEN IDENTIFIER > Token Identifiers are assigned by the Registration Authority. > 9.3.8 The information in item 8 to 14 is used by the Registration Authority > to construct a token identifier for the Cultural Specification according to > the following rules. The token identifier may then be used to uniquely > identify a Cultural Specification in a manner that may be more indicative of > its contents than a mere numeric identifier. > For Narrative Cultural Specifications, POSIX Locales and FDCC-sets the token > identifier will be: > 8_9+11+12,13_14 > And for Charmaps and Repertoiremaps the token identifier will be: > 10+11+12,13_14 > where 11 and 12 and preceding pluses shall be omitted when not needed to > specify position, and 13 may be omitted after request from the Sponsoring > Authority, if this is a National Standardization Organization. > The HYPHEN character "-" may be substituted for the UNDERLINE character "_", > in order to align names with RFC 3066. > NOTE: A combination of a POSIX Locale or FDCC-set, and a > Charmap may be designated by the Locale or FDCC-set identifier and the > Charmap identifier separated by a solidus (/). > When referencing a Cultural Specification, the version number or parts > thereof taken from the right may be omitted, to refer to the Cultural > Specification with the highest digital version number available with the > given version number prefix. If the item 13 is an empty string, referencing > the token identifier without the preceding comma and items 13 and 14 shall > give the Cultural Specification with the highest digital version number, > thus giving preference specifications from National Standardization > Organizations. > NOTE: The version number may be used by the Sponsoring > Authority to mark major releases, minor revisions and error corrections. It > is recommended that major releases be reflected as the first number, minor > revisions in the second number, and error corrections in the third number. > EXAMPLE 1: _EU,CEN_3.5 for the CEN European POSIX Locale > EXAMPLE 2: da_DK,_2.4 for the Danish Standards Danish POSIX Locale > EXAMPLE 3: ISO_8859-1:1987,DS_1.0 for the DS Charmap for ISO 8859-1 > > End of Appendix 2 Accepted in principle. Headings will be added. > APPENDIX 3 > Technical and editorial comments on optional (non-POSIX) clauses > > Clause 8: National or cultural profiles of standards (Optional) > CD2 TECHNICAL #116 > Current text: > "Here profiles of standards can be listed, for example, OSI national > profiles, or profiles of the POSIX standards. See the POSIX ISO/IEC 9945-2 > standard for an example." > Problem and Action: > The reference to POSIX is out-of-date and obsolete. ISO/IEC 9945-2 now > contains system interface definitions, and does NOT contain an example of a > profile. > Remove the sentence "See the POSIX..." Partly accepted. The 1993 standard will be referenced. > Clause 11: Transformation of characters (Optional, Not recommended) > CD2 TECHNICAL #117 > Current text > Here transliterations and transformations of characters can be described, > for example transliteration rules between Latin, Greek and Cyrillic, or > fallback notation for some frequent letters. Also this is the place to write > about standards in the culture for character conversion. > In CD1 Objection #49, the US proposed removal of this clause because: > This is too vague to be useful, as the Danish example in Annex D > illustrates. > The Editor responded in the DoC: > 49. Not accepted. There are already many quite elaborate > transliteration specs in 14652 style. > The US recommends that this clause be annotated "Not recommended." > Rationale: The instructions on the content of this clause are too vague to > be useful (as the Danish example in Annex D illustrates). Not accepted. Translitteration support is becoming more common in current software and there is a need to give specifications on this. > CD2 TECHNICAL #118 > If actual, usable "elaborate transliteration specs in 14652 style" exist, > then at least one appropriate example should be cited (and added to the > Bibliography). This will provide that Sponsoring Authorities with a > well-formed example of what should be in this clause. Accepted. A reference will be given. > Clause 13: Use of special characters (Optional) > CD2 TECHNICAL #119 > Although the US comment CD1 OBJECTION #31 to "revise the text to clarify the > information about order" was not accepted, the text dealing with quotes in > Clause 13 has been revised and is clearer: > For quoting, the character pairs <"><">, <"><"> and > <"><">are used,; the first character in each pair is used to start a quote, > and the last to end the quote. Noted. > CD2 TECHNICAL #120 > Clause 13 is a collection of examples of use of special characters (or > advice on use in the case of the number sign). What is needed is a > definition stating exactly what "special characters" are. Accepted. > CD2 TECHNICAL #121 > Delete this line: > NUMBER SIGN <#> is seldomly used, and should be avoided. > Rationale: Dictating whether a country or region should make use of NUMBER > SIGN in its orthography is totally out of scope for this standard. Not accepted. This is part of the Danish example. > CD2 EDITORIAL #122 > The US notes that "seldomly" is grammatically incorrect. The correct usage > is "seldom". Accepted. > Clause 16: Personal name rules (Optional, Not recommended) > CD2 TECHNICAL #123 > Current text: > Personal naming differs from culture to culture, for example what is > considered the family name, how titles are used, are family names spelt > thruout in capital letters, and whether given names or initial are used. > Also the rules for children inheriting their fathers' and mothers' family > name, and what happens for married couples may be described here. > Problem and Action as stated in CD1 OBJECTION #50: > "While this may be interesting information, of what use is it to software > developers? For most countries, there are general conventions about family > names, but so many individual exceptions that the conventions cannot be > hard-coded into software. What is the justification for including this > information?" > The DoC was "Not accepted. see 33." (CD1 Objection #33 was a comment on the > Danish example in Annex D.) > DEFECTIVE DISPOSITION. While it was appropriate to refer Objection #33 to > the Danish NB for resolution, it is incumbent upon the editor to respond to > the problems identified CD1 Objection #50. > The US notes that the editor did correct "first" to "given" (as suggested in > #33). Not accepted. Issues like this can be addressed with TR 14652 technology. > CD2 TECHNICAL #124 > The US recommends that this clause be annotated "Not recommended". > Rationale: It is questionable that the information requested here, which may > include many exceptions, can be expressed in software. Not accepted. Issues like this can be addressed with TR 14652 technology. > Clause 17: Inflection (Optional, Not recommended) > CD2 TECHNICAL #125 > Current text: > "Languages vary much with respect to inflection, different forms of words > depending of the context. here the rules can be described or referenced. > Some common translation APIs today take some aspects of this into account, > eg. the UNIX gettext() functions deal with singular/plural forms of nouns." > Remove the sentence beginning "Some common translation APIs..." > Rationale: > First, gettext() is not a translation API; it is a messaging API. Second, > while it may have some very, very limited capabilities with respect to > singular/plural nouns in a few languages, it most definitely does NOT have > the capability of handling all the varying inflection rules that languages > around the world use. This is misleading at best and inaccurate at worst. Not accepted. Other software may have the ability to handle inflection. > CD2 TECHNICAL #126 > The US recommends that this clause be annotated "Not recommended". > Rationale: It is questionable that the information requested here, which may > quite complex for some languages (as shown by the Irish example), can be > expressed in software. Not accepted. Software is being produced to take account of this, for example translation software. > Clause 20: Numbering, ordinals, and measuring systems (Optional) > CD2 EDITORIAL #127 > In the technical comment on Clause 3: Numeric formatting, it was pointed out > that information on how numbers are "keyed in" could not be included since > Clause 3 is defined as a POSIX category, and "POSIX contains no information > about how numbers are "keyed in". > In case information about keying in is needed, the US provides the following > replacement text: > This clause includes the description of the measurement > system or systems used. (Usually, the measurement system is the ISO SI > system.). A description of how numbers are keyed in may be included here. > Use of decimal points and thousands separator shall be described in clause > 3. > This replacement text also fixes these defects: > (a) corrects the erroneous plural "decimal points"; > (b) changes "should" to "shall" in the last sentence. Clause 3 > is a required data element of a registration (as specified in clause 9.3.2). Noted. No such text is needed. > Clause 22: Date and time (Optional, Not recommended) > CD2 TECHNICAL #128 > Current text: > "This is for considerations in excess of clause 5, such as non-POSIX date > conventions, time zone names and daylight savings rules, and other written > expressions like "half seven" - what is then really meant - 06:30 as in > Germany or Denmark, or 07:30 as in Britain?" > The U.S. still objects strongly to including time zone information in > cultural narratives (as stated in CD1 Objection #51). > Remove the phrase "...time zone names and daylight savings rules..." > Additional Rationale: > Time zones cross national borders and so are not limited to a single > culture. Also, time zone information in a locale or cultural narrative was > labeled controversial in TR 14652, and it is incorrect to elevate it to > normative status in this standard. Not accepted. This spec is also in currently approved IS 15897, so there is no new elevation. See also response to US comment 1. > CD1 OBJECTION #51 > Section: Annex G, clause 22 (Date and time) > Current text: > Text is now in 9.4, clause 22 > "This is for considerations in excess of clause 5, such as non-POSIX date > conventions, time zone names and daylight savings rules, . . ." > Problem and Action: > Time zone names and daylight savings rules should not be in a cultural > narrative. Especially for large countries, there are too many zones and > local exceptions for this information to be useful. Time zones are > geographical and political rather than cultural. > Remove this clause. > 51. Not accepted. The information can be used to set TZ, and in the case of > more than one, it can be used to select the correct one. 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. > CD2 TECHNICAL #129 > The example is defective. "Half seven" is an English language phrase, and > means 7:30 am or pm (that is, 0730 or 1930 hours). The German phrase "halb > sieben" means only 0630. (The Danish NB is invited to supply the > corresponding Danish phrase for 0630.) > We also note that "half seven" is British usage. English-speakers in other > cultures (US and Australia, for example) say "half past seven." Accepted. Changed to: Other ways that time can be expressed. > 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. Not accepted. See response to US comment 1. > Clause 23: Coding of national entities (Optional, Not recommended) > CD2 TECHNICAL #131 > The US recommends that this clause be annotated "Not recommended". > Rationale: The instructions on the content of this clause are too vague to > be useful. Not accepted. There need not be any specific format for this, as it is freeform. > Clauses 26, 27, 28 and 30 (Optional, Not recommended) > CD2 TECHNICAL #132 > 26. Identification of persons and organizations > 27. Electronic mail addresses > 28. Payment account numbers > 29. Man-machine dialogue > The US recommends that these clauses be annotated "Not recommended". > Rationale: The definitions are vague, or contain information that is > application-specific rather than culture-specific. Not accepted. There need not be any specific format for this, as it is freeform. > End of Appendix 3 > APPENDIX 4 > US Comments on Annex D, Sample Narrative Cultural Specification for Danish > and Irish All of the comments in this appendix are not accepted. These comments will be relayed to the Danish member body for possible changes. > Objections specific to the Danish or Irish examples are listed here. > These US comments consist of new comments on the CD2, and earlier comments > (previously submitted with the US vote on CD1) that are still applicable to > the CD2. These are distinguished by the prefix "CD2" or "CD1". Some > objections are specific instances of general comments above. > In N 957 Disposition of comments on CD of 15897 (that is, CD1), the Editor > responded: > 28-38. These comments will be relayed to the Danish member > body for possible changes. > Comments 28-37 were not accepted for this reason. > Corrections to the Danish example should be done with input > from the Danish member body. The Danish member body is kindly invited to > provide suggestions for changes, if appropriate. > This consolidated list of comments is submitted to assist the Danish and > Irish NBs should they wish to address the US concerns expressed in the US > comment on this Annex as a whole. > > CD1 OBJECTION #28 > Section: Annex D, Clause 7 (National or cultural Information Technology > terminology) > Current text: > "The official Information Technology terminology is "Edb-ordbog", DS > 2049-1970, Gjellerup, København. A newer description can be found in Lars > Frank: "edb-ordbogen", Kommunetryk, København 1984." > Problem and Action: > Citing documents that were written 31 and 17 years ago as relevant for > information technology is not useful. Technology and its terminology change > so quickly that these documents must be out-of-date. Remove this clause. > Perhaps there are more recent IT vocabulary sources for Danish speakers that > could be cited. > > CD2 TECHNICAL #133 > Section: Annex D, Clause 11 > Current text: > "Transliteration of Cyrillic and Arabic is quite different from English > conventions. Examples of transliterated Cyrillic names are Tjajkovskij, > Gorbatjov, and Jeltsin; an example of a translitterated Arabic name is > Khadaffi. For a fallback notation of some letters, refer to the following > table:" > Problem and Action: > It still is not clear why the Danish Standards body wants to state that > transliteration "...is quite different from English" without giving a full > description, but that is their choice. However, do they really want to > provide a list of "fallback notation of *some* letters" (emphasis added)? > Wouldn't it be preferable to provide a full list? > Editorial: correct spelling of second use of "transliterated". > The US previously commented on this clause as follows: > CD1 OBJECTION #29 > Section: Annex D, Clause 11 (Transformation of characters) > Current text: > "Transliteration of Cyrillic and Arabic is very different from English > conventions. > For a fallback notation of some letters, refer to the following table: > original letter 2-char 1-char > Æ AE E > Ø OE Y > Å AA O > . . ." > Problem and Action: > According to Annex G, this clause is for defining transliteration and > transformations of characters ("...for example transliteration rules between > Latin, Greek and Cyrillic, or fallback notation for some frequent > letters...") Note that this cultural specification simply says that > "Transliteration of Cyrillic and Arabic is very different from English > conventions" without giving any specific information about the differences, > and without giving any information at all about how to do a transliteration. > In other words, this provides no concrete information that a software > engineer could use. The sentence "Transliteration of Cyrillic..." therefore > must be removed. > The fallback information is a bit more useful, but does not provide any > guidance about when such fallbacks are permitted. Can they be used any time > the original letters are not available, or are there restrictions against > their use in some circumstances? Are there requirements to keep an original > copy of the data so that data is not lost? > More information is needed on fallbacks to make this clause useful. > > CD2 TECHNICAL #134 > Section: Annex D, Clause 14 > Current text: > "The Danish letters <Ø> and <ø> are often misprinted. . ." > Problem and Action: > Is this still true, or was it true 8-10 years ago when much of this annex > was originally written? The Danish Standards group may wish to recheck this > information and see whether this still is relevant. > The US previously commented on this clause as follows: > CD1 OBJECTION #32 > Section: Annex D, Clause 14 (Character rendition) > Current text: > "The Danish letters <Øand <øare often misprinted. The stroke in the letters > is the problem. If you consider a rectangle box surrounding the letter, then > the stroke should cross from the upper right corner to the opposite corner." > Problem and Action: > First, is this information still accurate, or was it accurate 7-10 years ago > when commercial fonts were not as readily available as they are today? > A more general problem is how this Clause might be used for other cultural > specifications. If rendering issues with a single Danish letter are > considered the appropriate information to put here, what might a Traditional > Chinese cultural specification include, as it tried to explain all the > nuances of rendering traditional Han ideographs? Or an Arabic specification > that tried to explain how to render Arabic? > This section as described, and as this example shows, does not scale well > beyond languages and cultures that have one or two specific rendering > issues. This is inadequate and should be removed. > > CD2 TECHNICAL #135 > Section: Annex D, Clause 15 (Character inputting) > Current text: > "A proposed general input method is included in DS/ISO/IEC 9945-1 annex F." > Problem and Action: > This is incorrect. First, the reference to ISO/IEC 9945-1 is obsolete since > the standard has been reissued in 2002. Second, it is incorrect for the 1993 > version of ISO/IEC 9945-1 (which includes POSIX.1b). Annex F in that version > is about Portability Considerations, and contains no information about input > methods or Danish. > Annex E (Sample National Profile), and Section E.1 (Profile for Denmark) may > be the intended reference, but this also does not seem to include more than > cursory information about input methods. The only relevant text seems to be > Section E.1.2 (Character Encoding and Display; lines 73-75): > "For input, if the character name is undefined in the current charmap file, > the data shall be left untouched (including the character) and the > behavior is implementation defined." > This does not propose a general input method. The Danish Standards > organization must correct this reference, since it specifies a incorrect > annex in an obsolete version of the standard, and since there seems not to > be a description of a Danish input method anywhere in ISO/IEC 9945-1:1993. > > CD1 OBJECTION #33 > Section: Annex D, Clause 16 (Personal names rules) > Current text: > "Personal names are commonly spelt with the full first name, while use of > initials only is seen also. People are mostly addressed by voice by their > first name. The common address form is the informal "du", and the more > formal "De" is becoming more common. The family name is never spelt in > capital letters only,. . ." > Problem and Action: > This information is vague or useless. How would a software engineer use the > information that "People are mostly addressed by voice by their first name" > (which, by the way, should be their "given name", not their "first name")? > The fact that "De" is "becoming more common" tells an engineer nothing > concrete and so is useless. These sentences should be removed. > The US notes that "full first name" has been changed to "full first given > name" in CD2 15897. > > CD1 OBJECTION #34 (re Danish example) > Section: Annex D, Clause 17 (Inflection) > Current text: > "The Danish grammar is defined in "Retskrivningsordbogen". Danish has more > inflections than English, for example nouns will have 8 forms based on > indefinite/definite, singularis/pluralis and nominative+others/genitive." > Problem and Action: > First, why does the information about Danish inflection compare it to > English? Second, what would a software engineer be expected to do with these > two sentences? Referring someone to a book about overall Danish grammar > probably would have only the most limited value, but at least it points > toward an agreed-upon standard. But why call out inflection separately, > since it is only one part of grammatical rules? > This example simply illustrates why an earlier OBJECTION calls for removing > this clause all together. > Re Irish example: > The Irish example gives a minimal description of the complex inflection of > Irish Gaelic, and refers the user to specific grammar books. > CD2 TECHNICAL #136 > Section: Annex D, Clause 23 > Current text: > "...Denmark is situated about 54 - 58 degrees North, and 8 - 15 degrees > East. Denmark has an area of about 43.069 km2 and 5,2 mill inhabitants > (1995)..." > Problem and Action: > It's curious that Denmark wants to use a seven-year-old population figure. > According to Statistics Denmark 2002 (http://www.dst.dk/imf), the current > population is 5,4 million (rounded up from 5,374 million). > The Danish Standards organization may wish to update its information. > > CD1 OBJECTION #35 > Section: Annex D, Clause 23 (Coding of national entities) > Problem and Action: > An earlier OBJECTION describes why this clause should be removed. The > information here is such a random collection of factoids that it is useless. > > CD1 OBJECTION #37 > Section: Annex D, Clause 27 (Electronic mail addresses) and Clause 28 > (Payment account numbers) > Problem and Action: > Remove these sections, as explained in an earlier OBJECTION. These are not > cultural-specific. > > CD2 TECHNICAL #137 > Section: Clause 28 (Payment account numbers) > In Danish bank account numbers, is there a separator character between the > branch identification code and the bank account number? How long can the > branch account number be? > The textual description of the structure of numbering for Danish Postal Giro > accounts does not agree with the example. It is true that there are 7 digits > in the example, but there is also a hyphen. Why is the hyphen not mentioned > in the textual description? Is it always positioned between the 3rd and 4th > digits? > > CD1 OBJECTION #38 > Section: Annex D, Clause 30 (Man-machine dialogue) > Problem and Action: > Remove this section, as explained in an earlier OBJECTION. This is too vague > to be useful. > 38. See response 23. > The Editor's disposition on US comment 23 was: > 23. Not accepted. It is commonly accepted good procedures > for registries not to delete entries, or possibilities for entries. The > proposal here would invalidate already existing entries in the registry. > The Minutes of the WG 20 meeting #22 (N 932) show that this comment was not > accepted because "WG20 is not in a position to change the Danish > specification." > > End of US comments ------------- End Forwarded Message -------------