ISO/IEC JTC1/SC22/WG20 N957D2 L2/02-246 Title: Disposition of comments on CD of 15897 (draft) Date: 2002-06-16 Source: ISO/IEC JTC1/SC22/WG20 Status: WG20 draft References: SC22 N3266, SC22 N3341 In the following the dispostion of comments is given with respect to the CD ballot in SC22 N3341, Information technology - Procedures for the Registration of Cultural Elements. Disposition of comments: > Netherlands > NEN opposes the proposal to allow submissions to the Registration Authority that have not > passed a formal review by the parent body of the group that produced the original proposal. > Resulting detailed changes to N3266: Section 5.1: remove the paragraph under b) (on CEN > TC304), and rename the paragraph c) to b). Section 5.1: in (the new) paragraph under b), strike > "and Working Groups". Not accepted. CEN/TC304 is a TC and on level with JTC1, and should be allowed to submit applications, and WGs have a need to submit also. > Norway > The commenting period and other periods should be shorter, eg 30 or 60 days, to speed up the > processing. Not accepted. 3 months is likely to produce fuller comments on the registrations. > US National Body Disapproves the CD Approval Ballot for the revision of ISO/IEC > 15897:1999 - Procedure for the Registration of Cultural Elements > Comments on ISO/IEC 15897:200x Draft (dated 2001-07-01) > > > October 1, 2001 > > > OBJECTION # 1 > Section: FORWARD and multiple other places in the text > > Current text: > "This International Standard registers amongst other items Cultural FDCC-sets, > charmaps and repertoiremaps as defined in ISO/IEC TR 14652,. . ." > > Problem and Action: > 14652 has not been approved as a TR, so it is inappropriate to refer to > it in this document. Remove the reference to ISO/IEC TR 14652 here and > elsewhere in this draft. 1. Not accepted. 14652 was approved by JTC 1. > EDITORIAL # 2 > Section: INTRODUCTION > > Current text: > "Cultural differences throughout the world make it necessary to adopt > IT-equipment to each local culture. Standard methods, being developed by > ISO/IEC JTC1/SC22, make such adoption easier. . ." > > Problem and Action: > The requirement is to *adapt* computers and IT equipment, not *adopt*. Change > the wording to "...make it necessary to adapt IT equipment..." and "...make > such adaptation easier..." 2. Accepted > OBJECTION #3 > Section: INTRODUCTION > > Current text: > ". . . This edition > of the International Standard adds support for ISO/IEC TR 14652, SGML and other > techniques meant for machine processing, and opens up the possible Sponsoring > Authorities." > > Problem and Action: > As noted previously, remove incorrect references to ISO/IEC TR 14652. Also, > rewrite the end of the sentence as "...and opens up the possibility of > Sponsoring Authorities" which presumably is what the text means to say. 3. For 14652 see 1. Sponsor Autorities will be clarified > OBJECTION #4 > Section: INTRODUCTION > > Current text: > "...registered cultural elements will also be freely available on the network > at the address http://www.dkuug.dk/cultreg/. This will make information on > cultural conventions freely and easily available to producers in the IT market. > Some of these conventions can even be implemented automatically by downloading > the formatted specifications." > > Problem and Action: > 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. Thus, the sentence should end "...will also be freely available." > > Also, remove the last sentence ("Some of these conventions can even be > implemented automatically..."). This is incorrect. Software has to interpret > the formatted specifications; simply downloading them doesn't automatically > implement them. 4. Accept in principle. The text will be changed to also point to the ISO web pages http://www.iso.org/mara/ The text will be changed to reflect that with some software eg complying to POSIX, you can automatically apply them. > OBJECTION #5 > Section: 1 SCOPE, 1st paragraph > > Current text: > "This International Standard specifies the procedures to be followed in > preparing, publishing and maintaining a register of cultural specifications > for computer use, including freeform narrative cultural elements > specifications, POSIX Locales and Charmaps conforming to ISO/IEC 9945-2, and > FDCC-sets, charmaps and repertoiremaps as defined in ISO/IEC TR 14652, and > SGML. The registry is in printed and electronic form, and the text of the > cultural specifications are recorded in a way that is independent of any coded > character set." > > Problem and Action: > There are multiple problems with this text. Based on the contents of the entire > document, the IS specifies the information that may appear in a cultural > specification, and also defines the procedures for *registering* such > specifications. It does not specify how to prepare or maintain the specs. > Also, this should not refer to 14652, as explained previously, and it is not > true that the text of cultural specifications is independent of any coded > character set. Clause 6.4 states that "The coded character set > ISO/IEC 646...shall be used to represent text for the submitted files." > > Because of all this, rewrite this paragraph as follows: > "This International Standard specifies the information that may appear in a > cultural specification and defines the procedures for registering such > specifications. The cultural specifications may include freeform narrative > cultural elements specifications, POSIX Locales and Charmaps conforming to > ISO/IEC 9945-2, and SGML. The registry is in printed and electronic form." > > Note: I will not specifically call out further references to ISO/IEC TR 14652, > but they must be removed. 5. Accepted. 14652 will be added to the list, as: "or FDCC-sets, repertoiremaps and charmaps following the recommendations of TR 14652". > OBJECTION #6 > Section: 1 SCOPE, last paragraph > > Current text: > ". . . Registered items using certain POSIX formal specification methods can > also be used by the POSIX Operating System and other software capable of > using such specifications." > > Problem and Action: > There is no such thing as *the* POSIX Operation System. Revise the text as > "...can also be used by POSIX-conformant Operating Systems and other > software..." 6. Accepted > EDITORIAL #7 > Section: 2 NORMATIVE REFERENCES > > Current text: > ". . .For dated references, subsequent amendments to, or revisions of, any of > these publications do not apply." > > Problem and Action: > Unclear text. Revise as "For dated references, any revisions of, or subsequent > amendments to these publications do not apply." 7. The standard ISO wording will be used. > EDITORIAL #8 > Section: 3 DEFINITIONS > > Current text: > "3.5 Cultural Convention: A data item for computer use that may vary dependent > on language, territory, or other cultural circumstances." > > Problem and Action: > Change "dependent" to "depending". 8. Accepted > OBJECTION #9 > Section: 3 DEFINITIONS > > Current text: > "3.7 Narrative Cultural Specification: A narrative description for computer > use of culturally dependent information, further described in 6.2." > > Problem and Action: > How does a computer use any narrative description? Of course, it doesn't. > Software engineers use the descriptions to write software that does the right > thing no matter what the user's language or cultural preferences. A better > definition is "A narrative description of culturally dependent information. > Such information may be useful when designing computer systems and software. > See Clause 6.2." 9. Accepted. the narrative spec only addresses items relevant for computer use. will be clarified. "pertaining to software use on computers". > 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. 10. Accepted in principle. The proposed RAC will address this problem, as well as the N945R contribution, which will be taken into account when writing the next draft. > OBJECTION #11 > Section: 4 REGISTRATION AUTHORITY > > Current text: > "The Registration Authority shall maintain a register of Cultural > Specifications and their numeric and token identifiers." > > Problem and Action: > The Authority is maintaining a *registry*, not a *register*. Also, what are > token identifiers and why are they used? Section 6.8 mentions what a token > idenfier will be for some items, but does not define what a token identifier > is. > > Add information at an appropriate place in this document about what a token > identifier is, why it is used, and how it is assigned. Add a reference in > Section 4 to this information. 11. Accepted. a definition of token identifier will be added. > OBJECTION #12 > Section: 4 REGISTRATION AUTHORITY > > Current text of 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;" > > Problem and Action: > 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 in the character set list, but the locale does not include > it in the class. Now what? Which is considered wrong? Is one rejected, > or asked to be revised? What if the locale was registered a few years ago, and > changing attitudes now make the fact that is not included obsolete? > To give a concrete example, locales from the early 1990s often include a > limited repertoire of characters -- Western European ones may only include a > subset of ISO 8859-1 characters. Locales (or cultural specifications) written > now often take a broader definition of what should be included. Under this > clause, is one of these wrong? What must be done? Should the older one be > marked obsolete? What about users who depend on it? > > The existing text is incomplete and vague about the Registration Authority > should do if a contradition exists. More information must be added -- once > decisions about what happens have been made. 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. N945R is addessing this, and text will be added to clarify it. > OBJECTION #13 > Section: 4 REGISTRATION AUTHORITY > > Current text of item g): > "to assign to the Cultural Specification appropriate token identifiers based > on the information given by the Sponsoring Authority,. . ." > > Problem and Action: > Again, what are token identifiers and how are they used? 13. Accepted, see 11 > OBJECTION #14 > Section: 4 REGISTRATION AUTHORITY > > Current text of item j): > "In the case of comments, to optionally receive from commenters text to be > added to the registration as comments." > > Problem and Action: > 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. 14. Noted. probably the SA, RA and the RAC could submit comments. N945R will be taken into account. > OBJECTION #15 > Section: 4 REGISTRATION AUTHORITY, last paragraph > > Current text: > ". . . When a standard is revised that has been used as basis for a Narrative > Cultural Specification, a POSIX Locale, FDCC-set, Charmap, or Repertoiremap, > these are not changed in the register." > > Problem and Action: > Unclear text. Does this mean: "If an existing entry in the registry is based on > a standard that subsequently is revised, the existing registry entry is not > changed." 15. Accepted > OBJECTION #16 > Section: 5 SPONSORING AUTHORITIES > > Current text: > "Proposals for registrations may also come from other sources, e.g. firms or > organizations. These must be referred for consideration to the Sponsoring > Authorities as noted below." > > Problem and Action: > "...as noted below" where? 16. Accepted in principle. They should send an application via a SA. Text to be added to that effect. > OBJECTION #17 > Section: 5 SPONSORING AUTHORITIES > > Problem and Action: > Why do Sponsoring Authorities have among their responsibilities ensuring that > proposals comply with the IS rules (clause 6), and that POSIX locales and > narrative cultural specifications do not contradict each other? Those are > listed as Registration Authority responsibilities in Section 4. Why the > duplication of effort and jobs? Who really owns these tasks? 14. Noted. N945R will be taken into account. > OBJECTION #18 > Section: 6 RULES FOR PROPOSALS > > Current text: > "1. The Narrative Cultural Specification shall specify cultural conventions in > narrative English, French and/or Russian, and may give equivalent > specifications in other languages." > > Problem and Action: > According to Annex H, French and Russian are added in this version of the > draft. Although many ISO standards are written in English and French, and so > the addition of French is not surprising, the addition of Russian is. What is > the rationale for doing so? As currently written, a specification could be > written in Russian only and then added to the registry. Would any Registration > Authority be likely to be able to review Russian-only text? If Russian is > added, why not add, say, Spanish? Japanese? Chinese? > > Russian should be removed from the list of languages here, unless there is a > compelling reason it should remain. Of course, specifications could be > submitted in English *and* Russian, or French *and* Russian under this rule, > but Russian-only should not be allowed. 18. Not accepted. Russian is an official ISO language. Clarified with "any of the official ISO languages: English, French, or Russian" > OBJECTION #19 > Section: 6 RULES FOR PROPOSALS > > Current text: > "Type 4 are for repertoiremaps defined in this International Standard and in > ISO/IEC TR 14652 (which are technical equivalent)." > > Problem and Action: > The reference to 14652 is incorrect, but in what sense are the two documents > cited technically equivalent? Repertoiremaps are only mentioned in passing > here; the syntax does not appear in this draft. Therefore, this text is > incorrect and must be changed. 19. Partially accepted. repertoiremaps are defined in clause 6, "Technically equivalent" will be removed. > EDITORIAL #20 > Section: 6 RULES FOR PROPOSALS > > Current text: > "5. In case of a TR 14652 FDCC-set, or other machine-parsabe cultural > specification, it..." > > Problem and Action: > Should be "machine-parsable". In addition, the reference to TR 14652 is > incorrect. 20. Accepted, for 14652 see 1. > OBJECTION #21 > Section: 6.1 > > 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,. . ." > > Problem and Action: > What is the rationale for specifying the paper size here? Unless there is a > good reason, this should be removed. 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. > OBJECTION #22 > Section: 6.2 (and Annex G) > Problem and Action: > 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. However,... 22. Accepted. > OBJECTION #23 > Section: 6.2 > > Problem and Action: > Some items currently listed as being allowable within a cultural specification > should be removed. Among those are: > > * Inflection -- There is no simple way to explain such a grammatically > complex issue as inflection, and no reason this one aspect of grammar > should be called out in a cultural specification. > * Coding of National Entities -- This is defined in Annex G as containing > "coding for different entities...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." This is so > vague as to be useless, and in fact, the contents of this section in the > Danish cultural specification in Annex D bears little relation to this > description. That section includes, among other things, information about the > longitude and latitude of Denmark, its area in kilometers, its population, the > name of the Danish language in Danish, the name of the currency, and other > facts. The section does include the fact that "postal codes are 4 digits", > which does relate to the description of this item, but this information is > too meager for any software engineer to actually use it. This section is too > vague. > * Electronic Mail Addresses -- Such addresses are a function of the software > that uses them; not of cultural requirements. > * Payment Account numbers -- These are application-specific, not > cultural-specific. > * Man-machine dialogue -- The full description in Annex G for this item is > "Considerations for how to localize products may be described here." Again, > this is so vague that it is useless and should be removed. > > NOTE: Further comments on the items currently allowed in a cultural > specification will appear in Annex G comments, below. 23. Not accepted. It is commonly acccepted good procedures for registries not to delete entries, or possiblities for entries. The proposal here would invalidate already existing entries in the registry. > OBJECTION #24 > Section: 6.4 > > 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), is used.. ." > Problem and Action: > Remove the sentence, "For enhanced network portability..." POSIX.2 does not > make this recommendation, and its portable character set includes nearly the > entire repertoire of ISO/IEC 646 IRV. There is no need to be more restrictive > in this document. 24. Not accepted. This is aligned with other specs in the field. > OBJECTION #25 > Section: 6.8 > > Problem and Action: > The text defines token identifiers for various different entities, but does > not explain the purpose of those identifiers. This information should be added. 25. Accepted > OBJECTION #26 > Section: 6.9 > > Current text: > ". . .and optionally the long ISO/IEC 10646 character name. It is recom- > mended to use, whenever possible, character names specified in ISO/IEC > 9945-2:1993 Annex G." > > Problem and Action: > Remove the sentence "It is recommended..." The character names mentioned here > are from the Danish National Locale Example in POSIX.2. There is no reason > these character names should be recommended. Rather, as noted previously in > the text, the ISO/IEC 10646 names should be used and comments as needed added > to help make the names more readable. 26. Not accepted. There is a reason, namely that you then can reuse a lot of data, eg for charmaps. > OBJECTION #27 > Section: Annex D, Clause 3, 4, 5, 6 > > Problem and Action: > All information shown in these clauses (Numeric formatting, Monetary > formatting, Date and time conventions, Affirmative and negative responses, > respectively) already is covered in ISO/IEC 9945-2 (POSIX.2). There is no > reason to repeat it here. Remove these clauses. 27. Not accepted. In these clauses you can add more information > 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. 28-38. These comments will be relayed to the Danish member body for possible changes. 28. Not accepted. Yes these documents are still relevant. > 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. 29. Not accepted. It is relevant to the software engineer that here is a problem and that more information is needed . The SW eng is warned that english transliteration is not useful. A narrative spec can contain different levels of information and all is probably useful. A litte info is probably beeter than none. > OBJECTION #30 > Section: Annex D, Clause 12 (Character properties) > > Current text: > "The Greenlandic letter KRA < > has no uppercase equivalent, and is converted > to a "Q" as also prescribed by modern Greenlandic orthography." > > Problem and Action: > This is the first mention of Greenlandic KRA. If it should be considered > part of Danish, it should be mentioned in Clause 1 (Alphanumeric deterministic > ordering) and Clause 9 (Character set considerations). Either add it to the > earlier clauses, or remove it here. 30. Not accepted. It is not part of Danish, but part of the foreign letters that Danish has rules for. > OBJECTION #31 > Section: Annex D, Clause 13 (Use of special characters) > > Current text: > "For quoting, the characters <"><">, <»><«> and <"><"> are used, with > the shown order." > > Problem and Action: > This text is unclear. Does "with the order shown" mean that plain quotes are > preferred, then guillemets, then fancy quotes? Or does it mean that when using > plain quotes, use them in the order shown, and when using guillemets, use them > in the order shown, etc.? > Revise the text to clarify the information about order. 31. should be clarified to the latter by the Danish NB. > 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. 32. The Ø problem is still there, unfortunately. Yes, more information could be added for eg han, and as disks are even more patient than paper, it should be possible to have space for elaborate specifications. > 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 > oncrete and so is useless. These sentences should be removed. 33. This gives guidelines for how to handle names, eg string space to set aside for names, and is also a way to document requirements that later can be codified. > OBJECTION #34 > 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. 34. Software engineers are probably expected to know english. inflection is specifically a problem, for translated texts, and eg gettext has specific support for some of this (singular/plural/more) grammar is getting supported now in many office systems. > 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. 35. It is used in apps, and 14652 supports it and MS also (AFAIK) > OBJECTION #36 > Section: Annex D, Clause 25 (Mail addresses) > > Current text: > "...The postal code is placed before the city name. The CEPT country prefix > should be places in front of the..." > > Problem and Action: > Spell out CEPT somewhere so that non-Europeans have a chance of understanding > what this means. Also, "...should be placed..." not "...should be places..." 36. CEPT may be spelled out > 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. 37. These codes are cultural habits, and something SW eng would like to know. > 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. > OBJECTION #39 > Section: Annex E ("reorder-after" construct in POSIX LC_COLLATE) > > Problem and Action: > 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. 39. Not accepted. These specs are also applicable to POSIX locales while 14651 specs are not. > 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 > collating elements after the collating symbol in the copied > specification. > . . . > 4. Thus for the original sequence > ... > this example reordering gives > ... Uu Vv Ww Xx ( Yy Üü ) Zz ( Ææ Ää ) Øø Åå > 5. . . . > the example reordering in E.3.1 gives > ... ( Uu Ùù Úú ) Vv Ww Xx ( Yy __ Üü ) ( Zz Zz ) > > ( Ææ ´Æ´æ ¯Æ¯æ Ää ) ( Øø ´Ø´ø Öö ) ( Åå ( AA Aa aA aa ) ´Å´å )" > > Problem and Action: > So much text is quoted because it is completely inconsistent. The example > syntax shows and , but not Å and å ( and ). The > explanation in item #2 includes neither the / pair, nor > . The reordering in item #4 shows , but not > /. The reordering in item #5 shows / and . > > 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). > OBJECTION #41 > Section: Annex F (Information on "reorder-after" construct in LC_COLLATE) > > Problem and Action: > 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. 41. Not accepted. See 39. > OBJECTION #42 > Section: F.3 (Sample POSIX Locale Specification for Danish and Irish Gaelic) > > Problem and Action: > Having these locale specifications in an annex that is supposed to describe > the rationale for the "reorder-after" construct makes no sense. These should > be in a separate annex. 42. Accepted > OBJECTION #43 > Section: Annex G > > Problem and Action: > As noted previously, the information in this annex should be included in > Clause 6 in the main section of this document. It is confusing and inconvenient > to have one-line items in the normative section, and then force users to search > elsewhere to determine what those one-line items mean. 43. Accepted, The Irish member body is invited to provide an updated annex. > OBJECTION #44 > Section: Annex G; 1st paragraph > Current text: > ". . . Clauses 1 to 6 are related to POSIX and the narrative description > should be accompanied by a corresponding POSIX Locale specification. . ." > > Problem and Action: > Nothing in the normative section of this document states that a narrative > description *and* corresponding POSIX locale specification should be submitted > together. Sections 4 and 5 say that such documents, if they exist, must not > be contradictory (see earlier objection about the vagueness of that > requirement), but do not imply, as this text does, that both a narrative and > a locale spec should be submitted together. > > Change the sentence to "Clauses 1 through 6 are related to POSIX." 44. Partillaly accepted. Text added: "If a POSIX locale is submitted, it is desiavble that it be accompaied with a related narrative cultural specification." > OBJECTION #45 > Section: Annex G, Clause 1 (Alphanumeric deterministic ordering) > > Current text: > ". . . Issues to cover are: 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? . . ." > > Problem and Action: > The world contains more than the Latin script, but nearly all examples and > explanation in this document (like this text) focus on European needs and > requirements of the Latin script. What about how Han ideographs are sorted in > relation to local phonetic scripts? What about Arabic presentation forms? What > about sorting of vowels and consonants? How about sorting requirements that > may not be expressible with the limited POSIX syntax? Should such requirements > be listed here, or in Clause 10? > > The text should take into consideration the needs of non-Latin scripts. 45. Accepted > OBJECTION #46 > Section: Annex G, Clause 3 (Numeric formatting) > > Current text: > "Here it is described how numbers are input and formatted,. . ." > > Problem and Action: > Neither of the examples in Annex D give any information about how numbers are > input. What does this mean? 46. Accepted. input means "keyed in" or "entered", text changed. > EDITORIAL #47 > Section: Annex G, Clause 4 (Monetary formatting) > > Current text: > "Here numeric formatting for monetary amounts is described as well as the > currency denominators, both locally and according to ISO 4217, are specified, > and the relation between the amount, a sign and the currency denominator is > specified." > > Problem and Action: > Grammatically ambiguous, and an odd term (currency denominator) for what > POSIX.2 calls the "currency symbol". Rewrite this as: "Here formatting rules > for monetary amounts, as well as local and international currency symbols, > are described." 47. Accepted > OBJECTION #48 > Section: Annex G, Clause 8 (National or cultural profiles of standards) > > 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: > Is there any country other than Denmark to whom this Clause applies? Denmark > has gotten locales published in POSIX, but others have not. > > If this only applies to Denmark, remove this clause. 48. Not accepted. Japan, Canada, The Netherlands, UK, China has also been working on national POSIX profiles. > OBJECTION #49 > Section: Annex G, Clause 11 (Transformation of characters) > > 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." > > Problem and Action: > This is too vague to be useful, as the Danish example in Annex D illustrates. > Remove this clause. 49. Not accepted. There are already many quite elaborate transliteration specs in 14652 style. > OBJECTION #50 > Section: Annex G, Clause 16 (Personal names rules) > > Current text: > "Personal naming differs from culture to culture. . . 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: > 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? 50. Not accepted. see 33. > OBJECTION #51 > Section: Annex G, Clause 22 (Date and time) > > Current text: > "This is for considerations in excess of clause 5, such as non-POSIX date > conventions, time zone names and daylight savings rules, . . ." > > Problem and Action: > Time zone names and daylight savings rules should not be in a cultural > narrative. Especially for large countries, there are too many zones and local > exceptions for this information to be useful. Time zones are geographical > and political rather than cultural. > > Remove this clause. 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. > OBJECTION #52 > Section: Annex G, Clause 23 (Coding of national entities) > > Problem and Action: > As noted in a previous objection, this information is too vague to be useful. > Remove this clause. 52. Not accepted. See 35 and 23 > OBJECTION #53 > Section: Annex G, Clause 27 (Electronic mail addresses) and > Clause 28 (Payment account numbers) > > Problem and Action: > As noted in a previous objection, these clauses are usually > application-specific, rather than culture-specific. Remove these clauses. 53. Not accepted. see 37 and 23 > OBJECTION #54 > Section: Annex G, Clause 30 (Man-machine dialogue) > > Problem and Action: > As noted in a previous objection, this information is too vague to be useful. > Remove this clause. 54. Not accepted. see 23 > OBJECTION #55 > Section: Annex H > > Current text: > "6. French and Russian were added as languages for narrative cultural > specifications." > > Problem and Action: > As noted in a previous objection, remove Russian as a language for narrative > cultural specifications. Note, however, that it would be fine to submit a > specification in Russian and English or Russian and French. 55. Not accepted. see 18 > OBJECTION #56 > Section: Annex H, Bibliography > > Current text: > "2. ISO/IEC TR 14652:2001 Information technology - Specification method for > cultural conventions." > > Problem and Action: > This document was not approved as a TR, so the reference here is incorrect. > Remove it. 56. Not accepted. see 1 End of disposition of comments