From rinehuls@access.digex.net Mon Jun 16 22:14:26 1997 Received: from ratatosk.DK.net (root@ratatosk.DK.net [193.88.44.22]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id WAA11950 for ; Mon, 16 Jun 1997 22:14:23 +0200 Received: from access5.digex.net (rinehuls@access5.digex.net [205.197.245.196]) by ratatosk.DK.net (8.6.12/8.6.12) with ESMTP id WAA12924 for ; Mon, 16 Jun 1997 22:13:59 +0200 Received: from localhost (rinehuls@localhost) by access5.digex.net (8.8.4/8.8.4) with SMTP id QAA15995 for ; Mon, 16 Jun 1997 16:12:40 -0400 (EDT) Date: Mon, 16 Jun 1997 16:12:39 -0400 (EDT) From: "william c. rinehuls" To: sc22docs@dkuug.dk Subject: SC22 N2491 - Revised Disposition of Comments Report on PDTR 10176 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 N2491 June 1997 TITLE: Revised Disposition of Comments Report on Concurrent PDTR Registration and PDTR Ballot for PDTR 10176 - Information technology - Guidelines for the Preparation of Programming Language Standards (Revision of TR 10176:1991) SOURCE: Secretariat, ISO/IEC JTC 1/SC22 WORK ITEM: JTC 1.22.13 STATUS: This document replaces SC22 N2411 CROSS REFERENCE: SC22 N2163, N2411 DOCUMENT TYPE: Disposition of Comments Report ACTION: To SC22 Member Bodies for information. Address reply to: ISO/IEC JTC 1/SC22 Secretariat William C. Rinehuls 8457 Rushing Creek Court Springfield, VA 22153 USA Tel: +1 (703) 912-9680 Fax: +1 (7030 912-2973 email: rinehuls@access.digex.net ___________________end of title page; beginning of text _________ Disposition of Comments Report CD ballot comments to PDTR 10176 COMMENTS ACCOMPANYING UNITED KINGDOM NEGATIVE VOTE UK COMMENTS ON ISO/IEC JTC 1/SC 22 N 2029 : GUIDELINES FOR PREPARATION OF PROGRAMMING LANGUAGE STANDARDS (ISO/IEC TR 10176 REVISED) The UK votes APPROVAL of the registration of this draft as a PDTR but DISAPPROVAL of the PDTR ballot for the technical reasons listed below:- Seq no: 1 Clause: 4.7 Kind: Major technical Problem: The guidelines for handling non-character set related issues within internationalization are minimal and unclear. These should be added before further progression of this report takes place. Proposed text: For WG20 - at the very least a minimal set should be specified and consideration should be given to selection mechanisms, especially that at the moment of process/thread initiation. Note a definition of "thread" and "process" will be needed Approved Disposition: The current draft of TR 10176 recommends that the internationalization functionality supported by each programming language standard should be cultural elements sensitive, and the cultural elements specification that are referred to by the internationalization functionality should be switch-able at run-time, instead of compile time. As pointed out, the current draft has no guidelines which suggests what kinds of internationalization functionality should be supported by each programming language standards. Instead, WG20 is now proposing an NP for an internationalization API. When the standard is established, the API will be able to called from every programming languages. Since the approved standard is now on quite early stage, the standard can not be refereed to by this TR. The standard will be refereed to by future revision of this TR. Seq no: 2 Clause: 4.1.3.1.1 Kind: Major technical Problem: No guidelines provided related to 10646 handling. Some text is in Note 3, but this is not a guideline in any way. Proposed text: Approved disposition: WG20 believe that provision of a CHARACTER data type that can contains the repertoire of ISO/IEC 10646 is sufficient for 10646 handling from the view point of programming language standards. Also, the PDTR recommends the use of a larger repertoire in ISO/IEC 10646 in user defined identifiers and CHARACTER literal. Seq no: 3 Clause: 3.6.16 Line: 1 Kind: Major technical Problem: Definition will be extremely unclear to readers who have not read 11017. Proposed text: Examples, as notes, should at least be provided here. Approved disposition: Accepted. Add note and list examples of cultural convention in it. Seq no: 4 Clause: 3.6.17 Line: 1 Kind: Major technical Problem: This is not a definition. Usage of "ideally located" is not acceptable, also term "application platform" needs to be defined. Proposed text: Approved disposition: This definition is the same wording as in the approved TR 11017. Seq no: 5 Clause: 4.1.3 Line: First two paragraphs Kind: Major technical Problem: These two paragraphs do not appear to relate to later guidelines. Proposed text: These need to be restructured as an overall heading for the sub-clause and some of the text moved into additional notes, e.g. justification. Approved disposition: Accepted. Seq no: 6 Clause: 4.1.3.4.2 Kind: Major technical Problem: Guidelines is inadequate in not making recommendations about classes of characters which should be provided for writing internationalised applications. Proposed text: To be reviewed by WG20, but should include firm recommendations related to upper/lower case, alphabetic, alphanumeric. Other categories may not be needed for internationalised applications and therefore should be added in a Note. Approved disposition: The character classifications exist in the WD of the cultural elements specification method standard (IS 14652). And WG20 believes that those classification should be supported by every programming language standard. Seq no: 7 Clause: 4.1.3.4.3 Kind: Major technical Problem: Clause appears to have no meaning, since "equivalent character semantics" is not defined. Proposed text: Firm guideline/recommendation from WG20 is required Approved disposition: Accepted. Describe the functionality by not using "equivalent character semantics". The clause would be as follows: "The programming language standard should provide a means to map a character to another, for example map an upper case letter to the corresponding lower case letter. The programming language standard should require that the means supplied do not depend on a specific coded character set, a specific culture, nor a specific natural language." Seq no: 8 Clause: 4.1.3.5 Kind: Major technical Problem: ISO 10646 does not have enough prominence. Proposed text: Move Note 5 before Note 1, also a guideline for the collating ordering if the standard supports 10646 should be provided, e.g. by ordering of character codes if nothing else. Approved disposition: Rejected. The subject standard is now being developed. Further revision of this TR may be able to emphasize the ordering of 10646 data, when IS 14651 is approved Seq no: 9 Clause: 4.1.3.5 Kind: Major technical Problem: No guidelines provided regarding switching of collating sequence dynamically. [Perhaps this should be applied in general to the switching of a character set as well?] Proposed text: For WG20 to provide. Approved disposition: Accepted. See 4.7.1 Seq no: 10 Clause: Annex C Kind: Major technical Problem: This appears to consist of many guidelines, in addition to some exposition, and should therefore be incorporated into the main body of the report. In addition many paragraphs duplicate wording elsewhere. Proposed wording: In addition to moving paragraphs a certain amount of rework may be necessary in the paragraphs new positions: Move C.1 para 1 + a) + e) to 4.1.3.3.2 Delete b) - duplicate in 4.1.3.6 Delete c) and d) - duplicates in 4.1.3.7 Move C.2.1 to 4.1.3.1.4 Move last sentence of C2.2. to 4.1.3.3.3 - rest is duplicate C.3 needs to be complete (probably) and moved elsewhere Delete C.4 unless some useful wording can be provided. Approved disposition: Accepted. Annex C will be removed. The contents of paragraph 1 will be moved to 4.1.3.3.1 and 4.1.3.3.2. Seq no: 11 Clause: 2 Line: last Kind: Minor Problem: Reference to BS 6154 out of date Proposed text: Change reference to DIS ??? Approved disposition: Accepted. (DIS 14977) Seq no: 12 Clause: 3.6.7 Line: 1 Kind: Minor technical Problem: Term "Execution environment" not defined Proposed text: Add definition Approved disposition: Accepted. Seq no: 13 Clause: 3.6.11 Line: 2-5 Kind: Minor technical Problem: Not part of a definition Proposed text: These sentences should form a Note or multiple notes. Approved disposition: Accepted. Add a note and move everything from the 2nd line on to the note. Seq no: 14 Clause: 3.6.11 Line: 4 Kind: English Proposed text: Replace "consists" with "consisting" and "type" with "type units" Approved disposition: Accepted. Seq no: 15 Clause: 3.6.11 Line: 5 Kind: English Proposed text: replace "character boundary need to be detached" with "the character boundary needs to be distinguished from the byte boundary" Approved disposition: Accepted. Seq no: 16 Clause: 3.6.11 Line: 6 Kind: English Proposed text: Replace "then become" with "thus becoming" and "Here after, T" with "In following references the" Approved disposition: Accepted. Seq no: 17 Clause: 3.6.12 Line: Last Kind: English Proposed text: Replace "Here after," with "In following references the" Approved disposition: Accepted. Seq no: 18 Clause: 3.6.12 Line: Middle Kind: Minor technical Problem: Not part of a definition Proposed text: Middle sentences should be a Note. Approved disposition: Accepted. Seq no: 19 Clause: 3.6.12 Line: Editors Note Kind: ? Problem: It's not clear what the purpose of this note is. Approved disposition: Remove Editor's note. No editor's note will remaine in the final text of this TR. Seq no: 20 Clause: 3.6.13 Line: 1 Kind: English Proposed text: Replace "The...VGA" with "A presentation device with a fixed width and height character font. A VGA" Approved disposition: Accepted. Seq no: 21 Clause: 3.6.14 Line: 1 Kind: English Proposed text: Delete "that is" and replace "alphabet." with "alphabet, a" Approved disposition: Accepted. Seq no: 22 Clause: 4.1.3.1 Line: 1 Kind: English Problem: Guidelines isn't about specifications Proposed text: Replace "specifications" with "text" Approved disposition: Accepted. Seq no: 23 Clause: 4.1.3.1.1 Line: Note 2 Kind: Minor technical Problem: Last line is not correct. Proposed text: Delete last sentence. Approved disposition: Accepted. Seq no: 24 Clause: 4.1.3.1.1 Line: Note 3 Kind: Minor technical Problem: Refers to bits Proposed text: Replace "sixteen or thirty one bit" with "multi-octet" Approved disposition: Accepted. Seq no: 25 Clause: 4.1.3.1.2 Line: 1 Kind: English Problem: Proposed text: Replace "character" with "characters" in title Approved disposition: Accepted. Seq no: 26 Clause: 4.1.3.1.2 Line: Note line 3 Kind: English Problem: Proposed text: Replace "has very similar to above" by "is very similar to these", "that the" to "that," "some of" by "some", "those" by "these", "works" by "acts", "delimiter" by "delimiters", "that have the identical or" by "the identical or a" Approved disposition: Accepted. Seq no: 27 Clause: 4.1.3.1.3 Line: Notes Kind: Recommendation Problem: These might be suitable as a basis for common notes at the head of this sub-clause. Approved disposition: Accepted in principle. Seq no: 28 Clause: 4.1.3.1.3 Line: Note 2 Kind: Minor technical Problem: Term "application" not defined Proposed text: Replace "application" by "the program" Approved disposition: Accepted. Seq no: 29 Clause: 4.1.3.1.4 Line: Para 3 Kind: Minor technical Problem: Does 10646 have the concept of an "escape character"? Proposed text: Remove "as an escape character or" Approved disposition: (Clarification) 1. ISO 10646 has the concept of ESC characters and escape sequences. Beside, the "Escape character" used in the text is a character that has a special meaning in a programming language, such as backslash character in C language. Seq no: 30 Clause: 4.1.3.1.4 Line: Editors note Kind: Minor technical Problem: Is the concept of a type for a literal well understood, especially for "extended character data type"? [Some languages will not have a need for the concept.] Proposed text: Additional Notes of explanation would probably be welcome. Approved disposition: The Editor's note will be removed from the final text of the TR. Seq no: 31 Clause: 4.1.3.1.4 Line: Note 1 second para Kind: Minor technical Problem: This para is incorrect, since these needs do not relate to "suitability of the language for general processing of character data." Proposed text: Remove para Approved disposition: Rejected. This text has not been changed from previous approved version. Seq no: 32 Clause: 4.1.3.1.4 Line: Note 2 Kind: Minor technical Problem: Note incorrect Proposed text: Remove note Approved disposition: Accepted. Note 2 removed. Seq no: 33 Clause: 4.1.3.2 Line: 2 Kind: Minor technical Problem: Refers to character data as a "sequence of octets". This may place a limitation on the language design, which does not need any concept of character length Proposed text: WG20 to review Approved disposition: A "Character" can be stored within CHARACTER or OCTET data type. To manipulate characters stored in the OCTET data type correctly, the programming language need to detect character boundary in OCTET string. The clause is prepared for C language. Seq no: 34 Clause: 4.1.3.2 Line: Para 2 Kind: English Problem: Proposed text: Replace "what" by "in what" Approved disposition: Accepted. Seq no: 35 Clause: 4.1.3.3.1 Line: 2 Kind: English Problem: Proposed text: Insert "the" before "extended" Approved disposition: Accepted. Seq no: 36 Clause: 4.1.3.3.1 Line: Note 1 Kind: English Problem: Proposed text: Insert "the" before "portability", replace "program" with "programs", insert "the" before "same", replace "string and" with "strings and data of", "those" with "this", delete "to", replace "bad mannered program," with "programs, the", "can" with ?fould" Approved disposition: Accepted. Seq no: 37 Clause:4.1.3.3.1 Line: Note 2 Kind: Minor technical Problem: Duplicate of 4.1.3.7 Proposed text: Delete note since it belongs better in clause 4.1.3.7 Approved disposition: Accepted. Seq no: 38 Clause: 4.1.3.3.2 Kind: English Proposed text: Replace "in a" with "in an" Approved disposition: Accepted. Seq no: 39 Clause: 4.1.3.3.3 Line: Title Kind: English Proposed text: Replace "subtype" with "subtypes" and "type" with "types" Approved disposition: Accepted. Seq no: 40 Clause: 4.1.3.3.3 Line: Para 1 Kind: English Problem: Proposed text: Delete "the particular", "particular" in line 2, insert "the" after "If", replace "support" by "supports", insert "should be" before "permitted", "the" before "current", replace "inter-kind" by "inter-type" Approved disposition: Accepted. Seq no: 41 Clause: 4.1.3.3.3 Line: last Kind: Minor technical Problem: "current FORTRAN" may not be correct in future. Proposed text: Replace "current FORTRAN standard" with the correct dated reference and include in clause 2. Approved disposition: Accepted. Seq no: 42 Clause: 4.1.3.4 Kind: English Problem: Proposed text: Insert "a" after "assumes", "for presentation" after "terminal", replace "with" with "as", insert "or octet length" after "byte length", replace "also should...test" with "should also provide functionality to determine", insert "that" before "will" Approved disposition: Accepted. Seq no: 43 Clause: 4.1.3.4.2 Kind: English Problem: Proposed text: Insert "the" before "means" Approved disposition: Accepted. Seq no: 44 Clause: 4.1.3.4.3 Kind: English Problem: Proposed text: Replace "a" be "the" Approved disposition: Accepted. Seq no: 45 Clause: 4.1.3.4.3 Kind: Minor technical Problem: Example in definition. Proposed text: Move second sentence into a Note. Approved disposition: Guideline rewritten. Seq no: 46 Clause: 4.1.3.6 Kind: English Problem: Proposed text: Insert "an" before "extended" Approved disposition: Accepted. Seq no: 47 Clause: 4.1.3.6 Kind: Minor technical Problem: Text appears to mandate a method of specification for a standard. Proposed text: Add Note: The programming language standard does not need to provide this extended character data type as a separate data type. Approved disposition: Accepted. Seq no: 48 Clause: 4.1.3.6 Line: Note 1 Kind: English Problem: Proposed text: Replace "ought not to" with "should not", "should should" with "should" and delete "but not so strongly recommended" Approved disposition: Accepted. Seq no: 49 Clause: 4.1.3.6 Line: Notes 1 Kind: Minor technical Problem: This appears to be specifying guidelines for the standard and so therefore should not be a Notes. However it appears to be predicated on a view of programming languages which does not apply to them all. Programming language should be allowed to handle composite sequences and therefore any guidelines should be about the issues in doing so, perhaps even providing a caution against doing this. Proposed wording: Needs major revision by WG20 Approved disposition: Rejected. SC22 Character set adhoc meeting resolved that the composite sequence does not need to be recognized as a unit for manipulation. The note simply says that for most programming language, the composite sequence is not a single character. In the case, if a programming language need to recognize the composite sequence as an unit for manipulation, this TR suggest the data type for the unit should not be CHARACTER. Currently no programming language recognize the composite sequence as an unit, this guideline should not be in main clause, but in a note. Seq no: 50 Clause: 4.1.3.6 Line: Note 2 last line Kind: English Problem: Proposed wording: Insert "and from" after "to" (twice) Approved disposition: Accepted. Seq no: 51 Clause: 4.1.3.6 Line: Note 2 Kind: Minor technical Problem: This is a guideline, not a note. However this guideline goes too far in suggesting solutions to the problem, since some languages may not need to have separate data types. Proposed wording: Remove Note 2 header and Replace "standard should provide" with "standard committee should consider the provision of" Approved disposition: Accepted. Seq no: 52 Clause: 4.1.3.7 Kind: English Problem: Proposed wording: Insert "the" after "If", "a" before "multi-byte", replace "character," with "characters,", "functionalities:" with "functionality:" Approved disposition: Accepted. Seq no: 53 Clause: 4.1.3.7 Line: a) Kind: Minor technical Problem: Over specifies guideline. Proposed wording: Delete "multi-octet" Approved disposition: Accepted. Seq no: 54 Clause: Annex A Line: Para 2 sentence 2 Kind: Minor technical Problem: Unnecessary explanation which could be contentious. Proposed wording: delete sentence 2 Approved disposition: Accepted. Seq no: 55 Clause: Annex A Line: para 3 Kind: Specification too restrictive. Problem: Proposed wording: Insert "minimal set of" after "recommended" Approved disposition: Rejected. The intention of the list in Annex A is to allow the full ISO 10646 character repertoire except special symbols for use in identifiers. Seq no: 56 Clause: Annex D Kind: Minor technical Problem: Doesn't seem to be relevant Proposed wording: Delete, but include reference in Note in 4.1.3.6 Approved disposition: Accepted. Annex D will be deleted. Seq no: 57 Clause: Annex D Kind: Minor technical Problem: Not relevant Proposed wording: Delete Approved disposition: Accepted. The Annex D will be deleted. Seq no: 58 Clause: Annex H Kind: Minor technical Problem: Too innovative and not thought through and stable enough Proposed wording: Delete unless adequate support from programming language standards committees is obtained. Approved disposition: Accepted. The annex will be deleted. ################################################# Denmark O1. the handling of character support is not consistent throughout the report. Approved disposition: Accepted. Rephrased. O2. the handling of internationalization support is minimal, and not to the level expected. This especially in the light of the recent failure of the NP for internationalization APIs. Approved disposition: Rejected. WG20 is proposing a NP for Internationalization APIs standard. The internationalization support functionality will be standardized by the standard. A future revision of TR 10176 will reference the Internationalization API standard. E3. 3.6.2 byte, add "or other data" (a byte can store integers, or parts thereof and also real etc.) Approved disposition: Accepted. The basic character data type will be replaced with OCTET data type, then the OCTET data type can store any data. O4. The terms 3.6.8 "basic character data type" and 3.6.10 "extended character data type" are misleading terms. The basic type can handle extended character sets. Rather call it something like multi-octet and widechar. Approved disposition: Accepted. Instead of using basic and extended character data type, CHARACTER and OCTET data type will be used. O5. 3.6.11 multi-byte representation and 3.6.12 multi-octet representation are misleading terms. In common sense a UTF-8 string would be multi octet, but this is not the meaning here (multi-octet is widechar only). Approved disposition: UTF-8 may be stored in 1 to 6 units of a data type whose bit length is one octet. The UTF-16 is stored in 2 units with a bit length of two octets. The term "multi-byte" is used for the data representation that uses multiple units, regardless of bit length of the unit. The term "multi-octet" is used for bit length of eight bit per unit. In this sense, UCS-2 is multi-octet and single byte, UTF-8 is single-octet multi-byte, and the UTF-16 is multi-octet and multi-byte. E6. 3.6.13. "A presentation device with fized ..." Add "The" before VGA. Is VGA defied? Approved disposition: Accepted. WG20 think VGA is a commonly used term. E7. 3.6.14. Add an "s" in complicated shape characters. Approved disposition: Accepted. O8. 4.1.1 delete guideline k) and l) as they are out of scope of this revision (which should only deal with i18n and charsets) Approved disposition: Accepted. E9. 4.1.3 second paragraph: replace "relating" with "relates". Approved disposition: Accepted. O10. 4.1.3 note 2 and 3, here we should rather use the distinction on the coded character vs abstract character model of annex H. Approved disposition: Rejected. The CHARACTER data type used in the TR is coding independent. E11.4.1.3 Editors note: Should probably read "Guideline: Use of other character sets" (note plural s on "sets". Also in "programming language standards". Delete plural "s" on character "sets" in line 5 of the paragraph. Insert "a" before "wider" in line 6. Approved disposition: Editor's notes will not remain in the final text of the TR. O12. 4.1.3.1.3 should indicate that the guideline is valid for all subsets of 10646 and however the subset is coded. The guideline now could be interpreted as only being valid for 10646 encoded strings. Note 2 of 4.1.3.1.3 should be enhanced with recent developments in the C++ and C working groups. That is also affecting annex D. Approved disposition: Accepted. O13. 4.1.3.1.4 literals. this should depend on the terminology of annex H, and when operating on the abstract level there there is no reference to encoding (UCS-2 or UCS-4). The numbering scheme could also be decimal instead of hex, as SGML and some programming languages. A "u" in front of the numbers should be recommended. Approved disposition: Partially accepted. The C++'s approach, the form of escape characters followed by SC2's character short identifier will be introduced. O14. 4.1.3.1.4 literals. there should also be ways of representing characters in literals that are not hexadecimal coded, as programming in hex is a bad programming style. Approved disposition: Although the hex representation is not so good practice, but is commonly used. Since the representation exist in the approved previous edition of this TR, the representation will remain in this edition. However, the approach of using short character identifier as defined by SC2 will be introduced. O15. 4.1.3.1.5 comments. This guideline should be more explicit and allow all characters in comments, except for some special characters and characters terminating the comment. Approved disposition: Accepted. O16. 4.1.3.3 character data types. This section should be replaced by the concepts in annex H. Approved disposition: Partially accepted. Those data types will be described by using CHARACTER data type which is independent from coding scheme, and OCTET data type. E17. 4.1.3.4.1 Add "a" after "assumes". Use "as" instead of "with" in "the same with". Approved disposition: Accepted. O18. 4.1.3.5 collating. Support for ISO/IEC 14651 should be recommended, and also support for other collating sequence specifications, as per POSIX and ISO/IEC 14652 (at CD consideration stage) . Approved disposition: Future release of this TR may recommend conformance level of IS 14652 when it is approved. O19. 4.1.3.6 and 4.1.3.7 should be rewritten in the light of annex H and also new teminology ala widechar/multibyte. Approved disposition: Rejected, since annex H will be removed. E20. 4.1.4.1.7 assignments. [d] should be reworded in light of annex H and new terminology Approved disposition: Rejected since annex H will be removed. O21. 4.7 should be enhanced with a recommended list of i18n functionality, as per the scope of the revision of the TR. Approved disposition: Rejected. The future revision of this TR will/may have guidelines based on the internationalization API standard (proposed). O22. B.1 i18n library. The TR needs to be enhanced by guidelines for i18n functionality, as per the scope of the revision of the TR. Approved disposition: Rejected. The future revision of this TR will/may have guidelines based in the proposed internationalization API standard. But the internationalization API is now in a quite early stage, therefore it is impossible to provide detailed guidelines in this edition. O23. C.1 10646 handling. The terminology in this annex is not convenient and also confusing with the definitions given. The annex should be revised in the light of annex H. Approved disposition: Annex C will be removed. O24. D.1 Should be reorded now that UTF-8 is full international standard. Also this is only to be recommended at the I/O boundary and a widechar model is to be recommended for internal processing. See text in annex H. Approved disposition: Annex D will be removed. O25. D.2 extended identifiers. This annex should be revised in light of recent developments in the C++ and C working groups. Approved disposition: Annex D will be removed. O26. multiple character set support. Should be enhanced with previously provided text from Danish standards. Approved disposition: Annex E will be removed. O27. H - character types. Should be moved to the main text. Approved disposition: Partially accepted. Although the annex H will be removed, the character data type related clause in the main body will be rewritten by using code independent CHARACTER data type and OCTET data type. ############################## COMMENTS ACCOMPANYING JAPAN NEGATIVE VOTE PDTR registration: Japan approves the subject test in ISO/IEC JTC1/SC22 N2029 "Concurrent PDTR Registration and PDTR Ballot for Revision of ISO/IEC TR 10176, Guidelines for preparation of programming language standards" to register as PDTR. PDTR consideration: Japan disapproves the subject text in ISO/IEC JTC1/SC22 N202 "Concurrent PDTR Registration and PDTR Ballot for Revision of ISO/IEC 10176, Guidelines for preparation of programming language standards" as PDTR with the following comments. Japan will change its position to approve if the following comments are reasonably accepted. Comments: Source: Japan Status: National body position Date: 1996-05-21 JAPAN-1 Annex A Extended repertoire for identifier Line 1 Minor technical Problem: Since there are not so many programming language standard that allows outside of ISO/IEC 646 character repertoire for user-defined identifier, it is too advance to recommend all of programming language standard to support those repertoire. In this sense, the wording "The programming language standard should allow...." is too strong. Proposed text: Programming language standard should not prohibit characters outside of ISO/IEC 646 repertoire for user-defined identifier, as far as possible. The programming language standard should implementation allow to use outside of ISO/IEC 646 for user-defined identifier. Approved disposition: Accepted. JAPAN-2 Annex A Extended repertoire for identifier Line 10-48 Minor technical Problem: The table is based on ISO/IEC 10646-1:1993, but amendments of the standards also reached to AM and DAM stage. The table should be maintained based on the AM and DAM. Proposed text: Since the ISO/IEC 10646 will be enhanced continuously. In order not to chase a moving target, the characters that should not be allowed for user-defined identifiers, e.g. mathematics symbols, should be specified narratively, instead of listing the characters that should be allowed. Approved disposition: Rejected. The annex is based on the current AMs of ISO/IEC 10646. This annex is subject to be revised in future revision of this TR. JAPAN-3 Annex B Guidelines for preparation of Internationalized library Line all Major technical Problem: Since the NP for Internationalized API has been voted down, the guidelines for the API does not needed. Each programming language standard should have free hand what kind of Internationalized API should be supported by the programming language, considering the user requirements to the language. Proposed text: Remove the annex. Approved disposition: Accepted. JAPAN-4 Annex C Issues on ISO/IEC 10646 handling Line all Major technical Problem: The contents of the annex looks being duplicated with the body part of the PDTR. Therefore, this annex is not needed. Proposed text: Remove the annex. Approved disposition: Accepted. JAPAN-5 Annex D.1 File System Safe UTF (UTF-8) Line all Major technical Problem: Since the subject encoding is specified by the ISO/IEC 10646-1 as an amendment, the explanation of the encoding is not needed in this PDTR. Proposed text: Remove the annex. Approved disposition: Accepted. JAPAN-6 Annex D.2 A suggested mechanism to support extended repertoire for identifier. Line all Major technical Problem: Since the ISO/IEC JTC1/SC2 specifies short identifier of character, per request from JTC1/SC22. The technical contents of the annex should be replaced with the one that utilize the short identifier. Guidelines should be provided for the use of the short identifier, perhaps for the clause 4.1.3.1.3 (user-defined identifier) and for the clause 4.1.3.1.4 (character literal) Proposed text: Remove all text of annex D.2, then add new guidelines into 4.1.3.1.3 and 4.1.3.1.4, if required. C++'s approach might be explained there. Approved disposition: Accepted. JAPAN-7 Annex E Multiple character set support Line all Major technical Problem: Since the contents of the annex is empty, this annex should be removed. Proposed text: Remove the annex. Approved disposition: Accepted. JAPAN-8 Annex H Advanced data type for character and string handling Line all Major technical Problem: Since none of programming language mandated the support of those data types, the recommendation of those data types are too advance for the current technology. The guideline described in the PDTR should be implemented by multiple programming language standards. The guideline that has not yet implemented by any programming language standard or only applicable single language standard should be removed from this PDTR. This PDTR should only contains guidelines to meet minimum requirements applicable for every language, as the previous edition of the TR did. Every advanced technologies should be left to the responsible language WG's decision. Proposed text: Remove the annex. Approved disposition: Accepted. ############################## COMMENTS ACCOMPANYING NETHERLANDS NEGATIVE VOTE ..................................................... 22N2029 PDTR 10176 Revision Guidelines for preparation of programming language standards 96-05-26, NO WITH COMMENTS ...................................................... The Netherlands does not approve of PDTR 10176:1995 because in our opinion, the current document does not show sufficient qualities to be acceptable: Comments General 1. The scope of the revision of TR 10176 (see for instance SC22/N1509) is to include guidelines on 2 topics: internationalization (based on the framework TR) and charactersets (specifically single-byte vs multi-byte issues in programming languages). However, guidelines for I18N are completely missing (presumably, because the framework is not ready). On the other hand in several places changes are proposed that are outside the scope of the revision (example: Introduction, 2nd paragraph after the note: it suggests to make the reason for non-adoption of a guideline available in an informative annex of the p.l. standard, rather than in the minutes of the meeting that made the decision. Why?? The 2nd sentence of this paragraph (badly written: the reason and the reason of the reason ???) makes it only worse). Should a revision of 10176 be taken up, standards prepared by WG11 should certainly be included. Approved disposition: The framework document DTR 11017 explains candidates of internationalization services but not all of them are relevant with programming language standard. This TR 10176 guided that the language culture dependent services which current programming language standards are supporting should be cultural convention set dependent, and the standards should provide a means to switch the cultural convention set dynamically. The TR allows programming language standards to have free hand what culture dependent service will be supported, therefore this TR has no guidance for the kinds of services that all programming languages should support. WG20 also initiated NP for internationalization API. It is intended that Internationalization API that should be commonly supported by programming languages will be specified by the standard, but the NP was failed. Regarding informative annex v.s minutes, the original sentence of the first edition will be maintained. (Accepted.) 2. The wording of the additions to the original 10176 frequently contains somewhat crippled English making it quite difficult to precisely understand the intended meaning. Several ambiguities and unclarities are noticeable (see in detailed comments). Approved disposition: See approved disposition of each detail comment. 3. The PDTR creates the impression that it tries to define terms and concepts regarding characters that are meant specifically for SC22. If this is accepted, nothing will resist other SCs, like SC18, to do the same thing. That languages like C and Pascal differ in their character concept is bad enough, but the PDTR should not add more confusion. We might have expected from WG20 a proper piece of research with respect to the commonalties and differences between the various concepts of character in existing programming languages. Approved disposition: WG20 believe that the concept/definition of "character" used in this TR is consistent with SC2's one. 4. Programming languages have a long tradition of striving for precision in describing the language. Contrary to this principle, the PDTR abounds in vague and confused statements, which demonstrate, assuming proper understanding of the English, several misconceptions about data types, character sets and semantics. For examples, see detailed comments). We doubt whether the author(s) have properly studied ISO/IEC 11404, Language independent data types. It would have prevented them from introducing concepts unnecessarily deviating from those in an approved standard. Approved disposition: Accepted. The character data type related clause will be rewritten by using CHARACTER and OCTET data type specified in ISO/IEC 11404. 5. Several Annexes are attached which, insofar as not being marked for deletion in the DTR, contain extensive preludes on issues like cultural conventions and string ordering, for which standards may or may not appear in the future. We want all these Annexes to be deleted. Approved disposition: Accepted except annex A. To change our vote to positive we require a second PDTR, in which all these defects have been repaired. In addition the following more detailed comments are presented for correction. At 2. Reference (s missing): ISO 6937-2:1983 : replace by ISO/IEC 6937:1994 and correct title. (change this at all other occurrences) Approved disposition: Accepted. At 3.6 change title into: Terms related to character coding and internationalization Approved disposition: Accepted. At 3.6.2 the definition of byte is not taken from SC2 standards, but that for octet is. Why? This is causing confusion. Approved disposition: A byte is not necessarily an octet. If character data type is defined as multi-octet length, the storage unit of the character data type can be called a byte. At 3.6.3 change origination into organization, in the NOTE change to: -- The definition above is that from the standards developed by ISO/IEC JTC1/SC2. Approved disposition: Accepted. At 3.6.7: This definition is utterly unclear. Approved disposition: Detail comments that points out each unclear definition will be highly appreciated. At 3.6.11 and 3.6.12: These definitions are very confusing. They suggest an essential difference between octet and byte which does not exist. What is described is not reflected in these names. What is presumably meant is coding with a varying number of octets and coding with a fixed number of octets. If so, say so. Approved disposition: Rejected. The byte is not necessary an octet. The byte could be 2 or 4 octet, in the case of UCS2, UCS4, and UTF-16. At 3.6.13, 3.6.14: Presentation issues are outside the scope of any programming language standard. Remove. Approved disposition: Accepted. At 3.6.17: This is unclear and premature. Remove definition. Approved disposition: Rejected. This definition comes from approved TR 11017. At 3.7.1: Remove definition. If a term is not used, it shall not be defined. Approved disposition: Accepted. At 4.1.3: Remove NOTE 2 and NOTE 3. Characters are not different because their coding is different. These notes confuse the concepts of character (which is code independent) and that of their coding. Approved disposition: Rejected. The notes exist in the approved first edition of this TR. At 4.1.3.1.1, last sentence: Apart from the SPACE these characters are control characters. The PDTR should use SC2 terminology. ---NOTE 1: This is an attempt to put the clock back. Restricting a programming language to only one pair of brackets is a major block to efficient parsing of programs. ---NOTE 2: Change ISO 6937-2 to ISO/IEC 6937. ---NOTE 3: Change to UCS-2 or UCS-4 of ISO/IEC 10646-1, because it is a Multiple-octet standard, not a 16-bit or 31-bit one. Approved disposition: Note 1: Rejected. These sentence exist in the first edition. Note 2: Accepted. Note 3: Accepted. At 4.1.3.1.2: Does this mean that every PL standard should be extended with an annex of more than 700 pages? Programming languages should not define characters based on their shape. Approved disposition: Rejected. COBOL standard recognize lower case A, upper case A, and double-width A are identical if those character is used in identifier. At 4.1.3.1.3: Remove second sentence. Annex A is not based on expertise on the scripts included (for example, it allows for Indian scripts only consonants in identifiers, not vowels), and is to be removed. The guideline should specify that IF the p.l. supports additional characters in an identifier, HOW this should be specified in the p.l., and probably how implementations should identify WHICH additional characters are available. ---NOTE 2: Remove second sentence. Annex D2 should go, too. Approved disposition: The annex A will be corrected based on the current AMs of ISO/IEC 10646. And the second sentence will be rewritten. At 4.1.3.1.4, a): Change to: The character is represented by its graphic symbol, e.g. ... ---NOTE 2: Remove. What is "inside a program"? ---NOTE 4: Change ISO 6937-2 to ISO/IEC 6937. Approved disposition: Rejected. Those exist in first edition of this TR. At 4.1.3.2: ---NOTE 3: Remove. Annex C should go. Approved disposition: Accepted. At 4.1.3.3.1 ---Remove. This definition repeats an earlier one. Approved disposition: The clause is rewritten. At 4.1.3.3.2: ---Remove. A datatype does not store anything. What is `a unit of the data type'? Approved disposition: The clause will be rewritten by using data repertoire that can be stored in the data type. At 4.1.3.4.1: ---Remove. Presentation matters are outside the scope of a programming language standard. Approved disposition: Accepted. At 4.1.3.4.2: ---Remove or rewrite. As it stands now, it is unclear. It may pertain to program text or to input characters, which need not to be served by the same classifications. Approved disposition: Accepted. It pertains to input characters. At 4.1.3.4.3: ---Remove. It is unclear what `equivalent character semantics' means. Furthermore, this matter may not be relevant to all programming languages. Approved disposition: "equivalent character semantics" will be replaced by other words. At 4.1.3.6: Remove NOTEs 1 and 2. The matter is sufficiently explained in ISO/IEC 10646-1 itself (4.13), and there is no need to repeat it here. Approved disposition: Rejected. At 4.1.3.7: Remove. It confuses again the concepts of character and coding. Remove all Annexes. See above under General. Approved disposition: Accepted except annex A. ___________________ end of document SC22 N2491 ______________________