From rinehuls@access.digex.net Wed Jul 16 22:11:32 1997 Received: from access4.digex.net (qlrhmEbBUV1EY@access4.digex.net [205.197.245.195]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id WAA11115 for ; Wed, 16 Jul 1997 22:11:25 +0200 Received: from localhost (rinehuls@localhost) by access4.digex.net (8.8.4/8.8.4) with SMTP id QAA20719; Wed, 16 Jul 1997 16:10:41 -0400 (EDT) Date: Wed, 16 Jul 1997 16:10:41 -0400 (EDT) From: "william c. rinehuls" X-Sender: rinehuls@access4.digex.net Reply-To: "william c. rinehuls" To: arnold winker , sc22docs@dkuug.dk Subject: SC22 N2520 - JTC 1 Voting Summary on DTR 10176 - Guidelines for Programming Language Standards Preparation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII __________________ beginning of title page __________________________ ISO/IEC JTC 1/SC22 Programming languages, their environments and system software interfaces Secretariat: U.S.A. (ANSI) ISO/IEC JTC 1/SC22 N2520 July 1997 TITLE: JTC 1 Summary of Voting on Approval of DTR 10176 - Guidelines for the Preparation of Programming Language Standards SOURCE: Secretariat, ISO/IEC JTC 1/SC22 WORK ITEM: JTC 1.22.13 STATUS: N/A CROSS REFERENCE: SC22 N2163, N2491 DOCUMENT TYPE: Summary of Voting ACTION: To SC22 Member Bodies for information. To WG20 for preparation of a Disposition of Comments Report and preparation of the final text for publication. Address reply to: ISO/IEC JTC 1/SC22 Secretariat William C. Rinehuls 8457 Rushing Creek Court Springfield, VA USA 22153 Telephone: +1 (703) 912-9680 Fax: +1 (703) 912-2973 email: rinehuls@access.digex.net ________________end of title page; beginning of summary __________________ ISO/IEC JTC 1 Information Technology ISO/IEC JTC 1 N 4782 DATE: 1997.06.25 REPLACES DOC TYPE: Summary of Voting/Table of Replies TITLE: Summary of Voting on Document JTC 1 N 4579, DTR 10176, Guidelines for the Preparation of Programming Language Standards SOURCE: JTC 1 Secretariat PROJECT: STATUS: Although the majority of P-members voted to approve this document, three P-members have submitted comments with their positive votes and three P-members have submitted negative votes. SC 22 is instructed to respond to these comments before submitting the TR for publication. ACTION ID: ACT DUE DATE: DISTRIBUTION: P and L Members MEDIUM: D DISKETTE NO.: 138 NO. OF PAGES: 13 Secretariat, ISO/IEC JTC 1, American National Standards Institute, 11 West 42nd Street, New York, NY 10036; Telephone: 1 212 642 4932; Facsimile: 1 212 398 0023; Email: lrajchel@ansi.org VOTING SUMMARY OF JTC 1 N 4579 "P" Members Approve Approve With Disapprove Abstain Comments Comments Australia * X Austria * X Belgium * Brazil * X Canada * X China * Columbia Denmark * X Egypt * X Finland * X France * X Germany * X Hungary Ireland * X Italy Japan * X See Comments Korea, Republic of X Netherlands * X See Comments New Zealand Norway * X Romania * X Russian Federation* X Slovenia * Sweden * X See Comments Switzerland * X United Kingdom * X See Comments USA * X See Comments * ISO/IEC "P" member of SC22 Attachment 1 Denmark Due to the change in ISO/IEC 10646 of the encoding of Hangul characters, we propose to change the allowable characters defined in the appendix on extended identifiers as follows. Remove the range: U3400..U4DFF Insert the range: UAC00..UD7AF Attachment 2 Japan Japan's Comments on ISO/IEC DTR 10176,Title: Information technology -- Guidelines for the preparation of Programming language standards The National Body of Japan approves ISO/IEC DTR 10176 with the following comments. 1. Category (Editorial) at the note 2 of 3.6.5 Proposed modification: replace "in not a" with "is not a". 2. Category (Editorial) in the subclause 3.6 Problem: the third level clause number 3.6.7 and 3.6.8 are duplicated. Proposed modification: renumber after the first occurrence of 3.6.8. 3. Category (Editorial) at the note 1 and 2 of 3..11 Proposed modification: replace "of character" with "of a character". 4. Category (Editorial) at the note 4 of 4.1.1 Problem: unnecessary line break exists. Proposed modification: reformat. 5. Category (Editorial) at the 4.1.3 Proposed modification: move ", e.g. ISO/IEC 10646-1" at immediate after of "multi-octet character set", and add ", e.g. ISO/IEC 8859-1" at the end of the sentence. 6. Category (Editorial) at the note 1 of 4.1.3.1.3 Proposed modification: replace "is by not English" with "is not English". 7. Category (Editorial) at the note 1 of 4.1.3.1.4 Proposed modification: remove the last sentence. Reason: The annex A does not discuss about possible solution. 8. Category (Editorial) at the first paragraph and note 1 of 4.1.3.3 Proposed modification: replace "every repertoire" with "entire repertoire". 9. Category (Editorial) at the note 1 of 4.1.3.3 Proposed modification: Replace "In the case if repertoire list which enumerate allowable repertoire of characters for the character datatype is not specified explicitly," with "In the case if the value space of a character datatype is not specified explicitly, by using the repertoire list that enumerate allowable repertoire of characters for the datatype," 10. Category (Editorial) at the last sentence of 4.1.3.3.3 Proposed modification: makes the last sentence as note and reword it as "Assignment from a character datatype whose value space is ISO/IEC 646 IRV to another character datatype whose value space is ISO/IEC 10646-1 is an example of inter character datatype assignment." . 11. Category (Editorial) at the second sentence of 4.1.3.4.2 Proposed modification: replace "couture" with "culture". 12. Category (Editorial) at the note 5 of 4.1.3.5 Proposed modification: replace "being standardized as CD 14651" with "being standardized towards ISO/IEC 14651". 13. Category (Editorial) at note of 4.7.2 Proposed modification: replace "TR 11017" with "ISO/IEC TR 11017". 14. Category (Technical) in Annex A Proposed modification: Add notes and clarify: (1) The character repertoire listed in this annex is based on the ISO/IEC 10646-1:1993, and subject to be changed if ISO/IEC 10646 is amended. (2) The character repertoire listed in this annex is a recommended repertoire for use of user defined identifier, and each programming language standard or implementation of the standard can modify the repertoire, considering the characteristics of the language and requirements, at the standardization or implementation of the language. 15. Category (Technical) in Annex A Proposed modification: Remove the following characters form the list: 309b-309e, 30fd, 30fe, 3094, 30f7-30fa, and characters in the compatibility zone (f900-ffdc). Attachment 3 Netherlands COMMENTS TO THE NEGATIVE VOTE Removal of Annex A is required to turn our NO vote into YES. This Annex contains rules for characters from scripts to be permitted in identifiers, without any indication that these are the right choice. Only the NBs of countries where these scripts are in use can state that, and these were not consulted. In particular, the rules for Indian scripts allow only for consonants, not vowels, in identifiers, which will cause great merriment in India, to the expense of the reputation of SC22/WG20 as a body of experts, and of SC22 as a serious standards developing group. A number of our comments in N 2163 appear to be proposed for rejection in N 2411 without any justification. Our vote will remain NO as long as no clarification is given. Editorial comments It is a pity that in a DTR still sentences occur not checked for correct English. Omission of the Definite or Indefinite Article is not allowed in the English language, a well known stumble-block to Japanese writers. Some are even not understandable. We mark these with This Sentence Is Incomprehensible (TSII). 3.6.3 Change: Each element of a combining sequence --> Each element of a composite sequence Add after last sentence: (as it is in ISO/IEC 10646-1.) 3.6.5 Change: (Note 2) A composite sequence in not --> A composite sequence is not --> 3.6.12 Note 2: Insert "the" and "a". 3.6.16 Note 2 Change: the same with --> the same as 4.1.3.1.2 Note 4 Change: for coding --> for character coding (SC29 is developing standards for audio-visual coding, not meant here.) 4.1.3.1.3 Note 3: The SC2 intends .... Remove this sentence. A TR is about facts, not intentions. 4.1.3.1.4 Note 3: Remove this note. A TR is about facts, not intentions. 4.1.3.2 Note 1 Change: variant --> version 4.1.3.3.1 Notes 1, 2 " " STII (see above) 4.1.3.4.2 Notes 1, 2, 3 STII (see above) "couture" ??? 4.1.3.6 Change: whose values space --> whose value space (NOTE): should not to require --> should not require --> 4.1.3.1.4, 4.7.2 Change: Programming language committee should consider --> The Programming language committee should consider --> Attachment 4 Sweden Editorial comment: The document has been typeset for US Letter format, which is evident from the uneven margins on even/odd pages when printed in A4 paper. Overall, the margins are too narrow for easy use, at least when printed on A4. Attachment 5 UK UK vote on JTC1 N4579 - DTR 10176: Document SC22/WG20 N477 The UK votes NO. The vote will become YES if Issues 1-3 and 12 are resolved satisfactorily. A number of issues which were identified as major technical issues in the PDTR ballot were not resolved satisfactorily, or at all, in the Disposition of Comments SC22 N2163: Issue 1: Clause 4.7 provided unclear and minimal guidance for the handling of non-character set related issues for internationalization. A recommendation for WG20 was made. Disposition: None provided, but a reference to TR 11017 Framework for internationalization exists. Action: 4.7.2 is especially unclear as to the meaning and needs to be clarified for subsequent processing. Issue 2: Clause 4.1.3.1.1 provided no guidelines for ISO 10646 handling. Disposition: Refers to CHARACTER datatype. Action: Datatypes are not relevant to character sets used for program text. Hence the original problem is still unresolved. Issue 3: Clause 4.1.3.4.2 makes no recommendations about classes of characters which should be provided for internationalized applications. Disposition: None Action: Recommendations need to be included. In addition a number of other issues need to be addressed: Issue 4: Clause 3.6.8 refers to a family when it is not clear that a family is being referred to. (Note the use of data type as two words or datatype as one word is inconsistent throughout.) Action: Change definition to A character datatype is a datatype whose value space is a character set. Also replace wide with large in the Note. Issue 5: Clause 3.6.9 muddles codes and values. Action: Replace definition with An octet datatype is the datatype whose values are single octets (often used for character sets and private encoding.) Also replace wide with large twice in the Note. Issue 6: Clause 3.6.10 is confused. Action: Replace definition with An octet string datatype is a dataype of variable-length whose elements are of an octet datatype. Also replace of extended character sets with an extended character set . Issue 7: Clause 3.6.12 could refer to non-integer multiples of octets Action: Replace that size is equal to or larger than two octets with whose values are multiple octets Issue 8: Clause 4.1.3.1.3 Note 2 last sentence refers to an Annex A which no longer exists. Action: Delete Issue 9: Clause 4.1.3.1.3 Note 3 last sentence refers to an SC2 intention. Action: Either delete or fully explain. Issue 10: In the DTR Clause 4.1.3.2 was identified as limiting to sequence of octets. Disposition: WG20 intended to review, but no changes have been made, so the problem is still outstanding. Action: WG20 should review before further progress. Issue 11: Clause 4.1.3.3.2 Notes 2 does not make any sense to this (English) reader. Is it trying to say that portability can be maintained if octet datatypes are used? This may be true for a limited subset of portability issues. If so then it should say which classes of portability would be maintained. Action: Needs to be re-written Issue 12: Clause 4.1.3.6 Note was recommended to be replaced with a guidelines. This was accepted by WG20, but no change has been made to the document. Action: Change needs to be made in response to original problem statement before f urther progression of the document. Issue 13: Clause 4.1.3.7 a and b) mentions octet-string when header refers to multi-byte Action: In a) delete stored in an octet string datatype In b) delete in an octet string datatype Issue 14: Many English problems Action: Issue : Clause 3.6.11 In Note 2 replace character bound with the character boundary 4.1.3.1.5 second sentence insert a after permit 4.1.3.3.1 Replace the character with a character and is by includes In Note 1 replace if by that a and emamerate by enumerate 4.1.3.3.2 Replace use by provide In Note 1 replace wide by large and all repertoire by all repetoires In Note 3 delete to 4.1.3.4.2 In second sentence replace couture by culture In Note 2 replace will be used by by should be usable by a 4.1.3.5 In the second paragraph replace one of by a 4.1.3.6 Replace the character by a character In the Note replace should not to by need not , should be stored in by could be stored in a In the final paragraph insert single value of a before datatype , the before provision , and replace distinct datatype from character datatype by datatype distinct from other character datatypes 4.1.3.7 Replace in by using In b) replace bound by boundary Attachment 6 USA The US National Body votes to Disapprove with comments ISO/IEC DTR 10176 - Guidelines for the Preparation of Programming Language Standards. See Comments listed below. Comments: General comments -------------------------- In general, we are finding TR 10176 rather uninformed about object-oriented language design and mostly irrelevant to the major new language development that it might be attempting to address, namely Java. We also finding that the document is anchored in the past in its usage of terminology and its application of coded character sets. These points are developed in the technical comments section. Furthermore, the document requires a lot of editorial work, there are many typos and many parts of the document are difficult to understand text sections. These issues are explained in the following editorial comments. Overall, the U.S. position is that the document should be withdrawn, unless it is completely rewritten to take into account the current language technology and submitted to a comprehensive editorial phase. Technical comments -------------------------- a) Byte terminology Ref: 3.6.1, 3.6.11 and 3.6.12 The usage of the byte terminology should be completely avoided. This document is redefining the byte in 3.6.2 in a manner slightly different from well known standards (for example ISO/IEC 2022:1994 defines it as 'a bit string that is operated upon as a unit'). Despite the fact that these definitions refer to the byte as an entity with a variable bit size, it is a well-established practice that the byte is assimilated to an octet. To avoid the issue, increasingly standards are referring only to the octet that has a very precise association with 8-bit encoding. Using the concept of multi-byte and two-octet bytes in the same sentence is more confusing than clarifying. b) Guideline: Character sets used for program text Ref 4.1.3.1.1 New languages should not be restricted to the usage of invariant part of ISO/IEC 646. This limitation is not realistic anymore and is de facto ignored by new languages. This would exclude characters like '[]{}|' that are commonly used in today languages. A vast majority of programmers is using environments based on (or related to) ISO/IEC 8859 or even ISO/IEC 10646, not national variants of ISO/IEC 646. This guideline is anchored in the past, not the present situation. c) Guideline: Guideline: Character datatype Ref 4.1.3.3.1 "The character datatype should be independent from any coded character set." The most recent developments in language technology like Java are being done, with good reasons, in contradiction with this guideline. The correct way to implement 10646 in a computer language is to *identify* the character datatype with a fixed-width encoding form of the universal character set. The point of a universal character set for a programming language is to *use* the universal character set directly, not simply to treat it as a reference by which to define all the single-byte, multi-byte anarchy that is currently implemented. d) Guideline: Character transliteration ref 4.1.3.4.2 This section distorts the standard meaning of "transliteration". What is meant here are classes of character transformation, explicitly case-transformation, and width-transformation (for Japanese hankaku/zenkaku characters). In addition, we presume that 'couture' was supposed to be 'culture'. e) Guideline: Cultural convention set switching mechanism ref 4.7.1 This guideline for provision of a mechanism such as setlocale() on a per-thread basis is too limited and inappropriate for object oriented languages like Java. Java provides I18N functionality through a set of classes which reflect an entirely different architecture. In general the guidelines in TR 10176 reflect a view of programming languages which generally seems to be completely uninformed by object-oriented programming language design. This is just one example. f) Recommended extended repertoire for user-defined identifier Ref Annex A The annex needs a complete reworking. This annex has errors scattered throughout. (e.g. U+0384 where U+0386 is clearly intended, in the Greek set) It is not up-to-date against Unicode 2.0 (or 10646 plus Amendments). For example, it arbitrarily omits the Hangul syllables (U+AC00 to U+D7AF3), and the CJK Unified Ideographs is a mixed bag containing characters that have nothing to do with Ideographs (Arabic presentation forms, Halfwidth and Fullwidth forms of Latin, Kana and Hangul,.). It also arbitrarily legislates against modifier letters or IPA values for identifiers. However, the worst error is in claiming that combining marks do not belong in identifiers. The fallacy of this can be seen by looking at the Devanagari list, which is utterly nonsensical. The recommended values for identifiers are U+0905-U+0939, U+0958-U+0962. In other words, this annex is recommending that *only consonants or initial vowels* are o.k. in Devanagari identifiers, but other vowels and virama should be omitted. See the Unicode Standard, pp. 5-25 to 5-27, plus corrections posted on the Unicode website, for a meaningful recommendation regarding how to extend identifier syntax to the 10646 repertoire. (The Java implementation of identifiers in Unicode is very close to this recommendation.) Editorial comments -------------------------- a) Guidelines on the use of character sets Ref 4.1.3 The following text "including multi-octet character sets and non-English single octet character sets, e.g. ISO/IEC 10646-1." is well intentioned, but badly worded, since it implies that 10646-1 is a single octet character set! This could be improved by swapping the two elements of the sentence. b) Guideline: Character sets used in character literals Ref 4.1.3.1.4 "Any conforming processor should be required to accept method c) to reepresent a character literal outside of "minimal set" defined in 4.1.3.1.1, any "non-printing character", or any special-purpose character, in a way that is independent from code value of the character of the character in any coded character set." We do not understand the meaning of the paragraph. The representation of a literal by its 10646 value cannot be independent of its code value *in* 10646, which is itself a coded character set. c) Guideline: Character sets used in comments Ref 4.1.3.1.5 (Note) Change "... Since comments are intended for human reading and hence escape mechanisms are unnecessary, there is no disadvantage in printing characters simply representing themselves (apart of course from any characters or sequences of characters marking the end of the comment), and in limiting non-printing characters to those (like carriage return and line feed) necessary for layout purposes." By "Program comments are intended for human reading. Except for the provision of unambiguous characters or sequences of characters to delimit the comments, the specification of a computer language should not restrict characters which can occur in comments. No escape mechanism should be necessary for inclusion of any character in comments." d) Guideline: Character datatype "The programming language standard should provide the character datatype whose value space is every repertoire of the extended character set in an execution environment." We don't understand that sentence. We presume this intends to say "the entire repertoire". Furthermore, the intent of the term "extended character set in an execution environment" is unclear. Note 1: "In the case if repertoire list which emamerate allowable repertoire of characters for the character datatype..." That note is completely incomprehensible. Besides the obvious typos (emamerate instead of enumerate, lack of articles, etc.), we cannot make any sense of the note. This defeats the purpose of this document that is aiming at being a set of 'guidelines'. e) Guideline: Octet and octet string datatype ref 4.1.3.3.2 Note 1 "The value space of the octet datatype is wide enough to represent every repertoire of the basic character set, but not all repertoire in the extended character set." Again, we don't understand this, we presume the author meant "the entire" for "every" and "all" here. The sentence needs to be completely rewritten (no suggestion as we don't understand it). __________________end of SC22 N2520 ___________________________________