From rinehuls@access.digex.net Sat Jun 8 00:38:46 1996 Received: from access2.digex.net (qlrhmEbBUV1EY@access2.digex.net [205.197.245.193]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id AAA07404 for ; Sat, 8 Jun 1996 00:38:37 +0200 Received: from localhost (rinehuls@localhost) by access2.digex.net (8.6.12/8.6.12) with SMTP id SAA27289 ; for ; Fri, 7 Jun 1996 18:38:01 -0400 Date: Fri, 7 Jun 1996 18:37:59 -0400 (EDT) From: "william c. rinehuls" X-Sender: rinehuls@access2.digex.net Reply-To: "william c. rinehuls" To: sc22docs@dkuug.dk Subject: Document SC22 N2163 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ISO/IEC JTC 1/SC22 Programming languages, their environments and system software interfaces Secretariat: U.S.A. (ANSI) ISO/IEC JTC 1/SC22 N2163 June 1996 TITLE: Summary of Voting on Concurrent PDTR Registration and PDTR Ballot for Revision of ISO/IEC TR 10176, Guidelines for preparation of programming language standards SOURCE: Secretariat, ISO/IEC JTC 1/SC22 WORK ITEM: JTC 1.22.13 STATUS: N/A CROSS REFERENCE: SC22 N2029 DOCUMENT TYPE: Summary of Voting ACTION: Registration of the PDAM is approved. To SC22 Member Bodies for information. To WG20 for preparation of a Disposition of Comment Report and a recommendation on further processing of the PDTR. 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 (703) 912-2973 email: rinehuls@access.digex.net ____________________________________________________________________________ SUMMARY OF VOTING ON Letter Ballot Reference No: SC22 N2029 Circulated by: JTC 1/SC22 Circulation Date: 1996-02-02 Closing Date: 1996-05-26 SUBJECT: Concurrent PDTR Registration and PDTR Ballot for Revision of TR 10176, Guidelines for preparation of programming language standards The following responses have been received on the subject of registration: 'P' Members supporting registration without comments: 11 'P' Members supporting registration with comments: 0 'P' Members not supporting registration: 2 'P' Members abstaining: 3 'P' Members not voting: 5 The following responses have been received on the subject of approval: 'P' Members supporting approval without comments: 9 'P' Members supporting approval with comments: 0 'P' Members not supporting approval: 4 'P' Members abstaining: 3 'P' Members not voting: 5 SECRETARIAT ACTION The PDTR has been registered. The comment accompanying the Swedish abstentions on registration and approval was: "Due to lack of resources." The comment accompanying the Austria abstentions on registration and approval was: "Lack of experts". The comments accompanying the negative votes on registration and approval have been forwarded to WG20 for preparation of a Disposition of Comments Report and a recommendation on furthe processing of the PDTR. ____________________________________________________________________________ ISO/IEC JTC1/SC22 LETTER BALLOT SUMMARY PDTR REGISTRATION PROJECT NO: JTC1.22.13 SUBJECT: Concurrent PDTR Registration and PDTR Ballot for Revision of ISO/IEC TR 10176, Guidelines for preparation of programming language standards Reference Document No: N2029 Ballot Document No: N2029 Circulation Date: 02-02-1996 Closing Date: 05-26-1996 Circulated To: SC22 P, L, O Circulated By: Secretariat SUMMARY OF VOTING AND COMMENTS RECEIVED Approve Disapprove Abstain Comments Not Voting 'P' Members Australia (X) ( ) ( ) ( ) ( ) Austria ( ) ( ) (X) (X) ( ) Belgium ( ) ( ) ( ) ( ) (X) Brazil (X) ( ) ( ) ( ) ( ) Canada ( ) ( ) ( ) ( ) (X) China ( ) ( ) ( ) ( ) (X) Czech Republic (X) ( ) ( ) ( ) ( ) Denmark ( ) (X) ( ) (X) ( ) Egypt ( ) ( ) ( ) ( ) (X) Finland (X) ( ) ( ) ( ) ( ) France (X) ( ) ( ) ( ) ( ) Germany ( ) ( ) (X) ( ) ( ) Japan (X) ( ) ( ) ( ) ( ) Netherlands ( ) (X) ( ) (X) ( ) Romania ( ) ( ) ( ) ( ) (X) Slovenia (X) ( ) ( ) ( ) ( ) Sweden ( ) ( ) (X) (X) ( ) Switzerland (X) ( ) ( ) ( ) ( ) UK (X) ( ) ( ) ( ) ( ) Ukraine (X) ( ) ( ) ( ) ( ) USA (X) ( ) ( ) ( ) ( ) 'O' Members Argentina ( ) ( ) ( ) ( ) ( ) Bulgaria ( ) ( ) ( ) ( ) ( ) Cuba ( ) ( ) ( ) ( ) ( ) Greece ( ) ( ) ( ) ( ) ( ) Hungary ( ) ( ) ( ) ( ) ( ) Iceland ( ) ( ) ( ) ( ) ( ) India ( ) ( ) ( ) ( ) ( ) Indonesia ( ) ( ) ( ) ( ) ( ) Italy ( ) ( ) ( ) ( ) ( ) Korea Rep (X) ( ) ( ) ( ) ( ) New Zealand ( ) ( ) ( ) ( ) ( ) Norway ( ) ( ) ( ) ( ) ( ) Poland ( ) ( ) ( ) ( ) ( ) Portugal ( ) ( ) (X) ( ) ( ) Russian Fed ( ) ( ) ( ) ( ) ( ) Singapore ( ) ( ) ( ) ( ) ( ) Thailand ( ) ( ) ( ) ( ) ( ) Turkey ( ) ( ) ( ) ( ) ( ) Yugoslavia ( ) ( ) ( ) ( ) ( ) ____________________________________________________________________________ ISO/IEC JTC1/SC22 LETTER BALLOT SUMMARY PDTR APPROVAL PROJECT NO: JTC1.22.13 SUBJECT: Concurrent PDTR Registration and PDTR Ballot for Revision of ISO/IEC TR 10176, Guidelines for preparation of programming language standards Reference Document No: N2029 Ballot Document No: N2029 Circulation Date: 02-02-1996 Closing Date: 05-26-1996 Circulated To: SC22 P, L, O Circulated By: Secretariat SUMMARY OF VOTING AND COMMENTS RECEIVED Approve Disapprove Abstain Comments Not Voting 'P' Members Australia (X) ( ) ( ) ( ) ( ) Austria ( ) ( ) (X) (X) ( ) Belgium ( ) ( ) ( ) ( ) (X) Brazil (X) ( ) ( ) ( ) ( ) Canada ( ) ( ) ( ) ( ) (X) China ( ) ( ) ( ) ( ) (X) Czech Republic (X) ( ) ( ) ( ) ( ) Denmark ( ) (X) ( ) (X) ( ) Egypt ( ) ( ) ( ) ( ) (X) Finland (X) ( ) ( ) ( ) ( ) France (X) ( ) ( ) ( ) ( ) Germany ( ) ( ) (X) ( ) ( ) Japan ( ) (X) ( ) (X) ( ) Netherlands ( ) (X) ( ) (X) ( ) Romania ( ) ( ) ( ) ( ) (X) Slovenia (X) ( ) ( ) ( ) ( ) Sweden ( ) ( ) (X) (X) ( ) Switzerland (X) ( ) ( ) ( ) ( ) UK ( ) (X) ( ) (X) ( ) Ukraine (X) ( ) ( ) ( ) ( ) USA (X) ( ) ( ) ( ) ( ) 'O' Members Argentina ( ) ( ) ( ) ( ) ( ) Bulgaria ( ) ( ) ( ) ( ) ( ) Cuba ( ) ( ) ( ) ( ) ( ) Greece ( ) ( ) ( ) ( ) ( ) Hungary ( ) ( ) ( ) ( ) ( ) Iceland ( ) ( ) ( ) ( ) ( ) India ( ) ( ) ( ) ( ) ( ) Indonesia ( ) ( ) ( ) ( ) ( ) Italy ( ) ( ) ( ) ( ) ( ) Korea Rep (X) ( ) ( ) ( ) ( ) New Zealand ( ) ( ) ( ) ( ) ( ) Norway ( ) ( ) ( ) ( ) ( ) Poland ( ) ( ) ( ) ( ) ( ) Portugal ( ) ( ) (X) ( ) ( ) Russian Fed ( ) ( ) ( ) ( ) ( ) Singapore ( ) ( ) ( ) ( ) ( ) Thailand ( ) ( ) ( ) ( ) ( ) Turkey ( ) ( ) ( ) ( ) ( ) Yugoslavia ( ) ( ) ( ) ( ) ( ) ____________________________________________________________________________ COMMENTS ACCOMPANYING DENMARK DISAPPROVAL VOTE The DS vote on pDTR 10176 registration is NO The DS vote on pDTR 10176 CD ballot is NO The following constitutes the coments for the two ballots. Overall the document is not structured as it would be needed for the technical report. Objections are marked "O" and editorial comments are marked with an "E" in the following. O1. the handling of characer support is not consistent thruout the report. 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. E3. 3.6.2 byte, add "or other data" (a byte can store integers, or parts thereof and also real etc.) 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. 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 mulit octet, but this is not the meaning here (multi-octet is widechar only). E6. 3.6.13. "A presentation device with fized ..." Add "The" before VGA. Is VGA defied? E7. 3.6.14. Add an "s" in complicated shape characters. 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) E9. 4.1.3 second paragraph: replace "relating" with "relates". 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. 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. O12. 4.1.3.1.3 should indicate that the guideline is valid for all subsets of 10646 and however the soubset is coded. The guideliner 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. 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. Prepending a "u" in front of the numers should be recommended. 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. 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. O16. 4.1.3.3 character data types. This section should be replaced by the concepts in annex H. E17. 4.1.3.4.1 Add "a" after "assumes". Use "as" instead of "with" in "the same with". O18. 4.1.3.5 collating. Support for ISOIEC 14651 should be recommended, and also support for other collating sequence specifications, as per POSIX and ISO/IEC 14652 (at CD consideration stage) . 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. E20. 4.1.4.1.7 assignments. [d] should be reworded in light of annex H and new terminology O21. 4.7 should be enhanced with a recommended list of i18n functionality, as per the scope of the revision of the TR. 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. 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. 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. O25. D.2 extended identifiers. This annex should be revised in light of recent developments in the C++ and C working groups. O26. multiple character set support. Should be enhanced with previously provided text from Danish standards. O27. H - character types. Should be moved to the main text. end of DS comments on CD pDTR 10176 ____________________________________________________________________________ COMMENTS ACCOMPANYING JAPAN NEGATIVE VOT 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. 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. mathematic symbols, should be specified narratively, instead of listing the characters that should be allowed. 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. 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. 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. 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. 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. 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. --------end of comments------ ____________________________________________________________________________ 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. 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). 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 commonalities and differences between the various concepts of character in existing programming languages. 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. 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. 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) At 3.6 change title into: Terms related to character coding and internationalization At 3.6.2 the definition of byte is not taken from SC2 standards, but that for octet is. Why? This is causing confusion. 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. At 3.6.7: This definition is utterly unclear. 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. At 3.6.13, 3.6.14: Presentation issues are outside the scope of any programming language standard. Remove. At 3.6.17: This is unclear and premature. Remove definition. At 3.7.1: Remove definition. If a term is not used, it shall not be defined. 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. 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. 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. 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. 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. At 4.1.3.2: ---NOTE 3: Remove. Annex C should go. At 4.1.3.3.1 ---Remove. This definition repeats an earlier one. At 4.1.3.3.2: ---Remove. A datatype does not store anything. What is `a unit of the data type'? At 4.1.3.4.1: ---Remove. Presentation matters are outside the scope of a programming language standard. 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. 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. 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. At 4.1.3.7: Remove. It confuses again the concepts of character and coding. Remove all Annexes. See above under General. ------------------------------eof--------------------------------- ____________________________________________________________________________ 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 internationalisation 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 ^Sthread^T and ^Sprocess^T will be needed 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: 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. Seq no: 4 Clause: 3.6.17 Line: 1 Kind: Major technical Problem: This is not a definition. Usage of ^Sideally located^T is not acceptable, also term ^Sapplication platform^T needs to be defined. Proposed text: 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. 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. Seq no: 7 Clause: 4.1.3.4.3 Kind: Major technical Problem: Clause appears to have no meaning, since ^Sequivalent character semantics^T is not defined. Proposed text: Firm guideline/recommendation from WG20 is required 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. 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. 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. Seq no: 11 Clause: 2 Line: last Kind: Minor Problem: Reference to BS 6154 out of date Proposed text: Change reference to DIS ??? Seq no: 12 Clause: 3.6.7 Line: 1 Kind: Minor technical Problem: Term ^SExecution environment^T not defined Proposed text: Add definition 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. Seq no: 14 Clause: 3.6.11 Line: 4 Kind: English Proposed text: Replace ^Sconsists^T with ^Sconsisting^T and ^Stype^T with ^Stype units^T Seq no: 15 Clause: 3.6.11 Line: 5 Kind: English Proposed text: replace ^Scharacter boundary need to be detached^T with ^Sthe character boundary needs to be distinguished from the byte boundary^T Seq no: 16 Clause: 3.6.11 Line: 6 Kind: English Proposed text: Replace ^Sthen become^T with ^Sthus becoming^T and ^SHere after, T^T with ^SIn following references the^T Seq no: 17 Clause: 3.6.12 Line: Last Kind: English Proposed text: Replace ^SHere after, T^T with ^SIn following references the^T 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. Seq no: 19 Clause: 3.6.12 Line: Editors Note Kind: ? Problem: It^Rs not clear what the purpose of this note is. Seq no: 20 Clause: 3.6.13 Line: 1 Kind: English Proposed text: Replace ^SThe...VGA^T with ^SA presentation device with a fixed width and height character font. A VGA^T Seq no: 21 Clause: 3.6.14 Line: 1 Kind: English Proposed text: Delete ^Sthat is^T and replace ^Salphabet.^T with ^Salphabet, a^T Seq no: 22 Clause: 4.1.3.1 Line: 1 Kind: English Problem: Guidelines isn^Rt about specifications Proposed text: Replace ^Sspecifications^T with ^Stext^T 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. Seq no: 24 Clause: 4.1.3.1.1 Line: Note 3 Kind: Minor technical Problem: Refers to bits Proposed text: Replace ^Ssixteen or thirty one bit^T with ^Smulti-octet^T Seq no: 25 Clause: 4.1.3.1.2 Line: 1 Kind: English Problem: Proposed text: Replace ^Scharacter^T with ^Scharacters^T in title Seq no: 26 Clause: 4.1.3.1.2 Line: Note line 3 Kind: English Problem: Proposed text: Replace ^Shas very similar to above^T by ^Sis very similar to these^T, ^Sthat the^T to ^Sthat,^T ^Ssome of^T by ^Ssome^T, ^Sthose^T by ^Sthese^T, ^Sworks^T by ^Sacts^T, ^Sdelimiter^T by ^Sdelimiters^T, ^Sthat have the identical or^T by ^Sthe identical or a^T 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. Seq no: 28 Clause: 4.1.3.1.3 Line: Note 2 Kind: Minor technical Problem: Term ^Sapplication^T not defined Proposed text: Replace ^Sapplication^T by ^Sthe program^T Seq no: 29 Clause: 4.1.3.1.4 Line: Para 3 Kind: Minor technical Problem: Does 10646 have the concept of an ^Sescape character^T? Proposed text: Remove ^Sas an escape character or^T 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 ^Sextended character data type^T? [Some languages will not have a need for the concept.] Proposed text: Additional Notes of explanation would probably be welcome. 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 ^Ssuitability of the language for general processing of character data.^T Proposed text: Remove para Seq no: 32 Clause: 4.1.3.1.4 Line: Note 2 Kind: Minor technical Problem: Note incorrect Proposed text: Remove note Seq no: 33 Clause: 4.1.3.2 Line: 2 Kind: Minor technical Problem: Refers to character data as a ^Ssequence of octets^T. This may place a limitation on the language design, which does not need any concept of character length Proposed text: WG20 to review Seq no: 34 Clause: 4.1.3.2 Line: Para 2 Kind: English Problem: Proposed text: Replace ^Swhat^T by ^Sin what^T Seq no: 35 Clause: 4.1.3.3.1 Line: 2 Kind: English Problem: Proposed text: Insert ^Sthe^T before ^Sextended^T Seq no: 36 Clause: 4.1.3.3.1 Line: Note 1 Kind: English Problem: Proposed text: Insert ^Sthe^T before ^Sportability^T, replace ^Sprogram^T with ^Sprograms^T, insert ^Sthe^T before ^Ssame^T, replace ^Sstring and^T with ^Sstrings and data of^T, ^Sthose^T with ^Sthis^T, delete ^Sto^T, replace ^Sbad mannered program,^T with ^Sprograms, the^T, ^Scan^T with ^Qcould^T 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 Seq no: 38 Clause: 4.1.3.3.2 Kind: English Proposed text: Replace ^Sin a^T with ^Sin an^T Seq no: 39 Clause: 4.1.3.3.3 Line: Title Kind: English Proposed text: Replace ^Ssubtype^T with ^Ssubtypes^T and ^Stype^T with ^Stypes^T Seq no: 40 Clause: 4.1.3.3.3 Line: Para 1 Kind: English Problem: Proposed text: Delete ^Sthe particular^T, ^Sparticular^T in line 2, insert ^Sthe^T after ^SIf^T, replace ^Ssupport^T by ^Ssupports^T, insert ^Sshould be^T before ^Spermitted^T, ^Sthe^T before ^Scurrent^T, replace ^Sinter- kind^T by ^Sinter-type^T Seq no: 41 Clause: 4.1.3.3.3 Line: last Kind: Minor technical Problem: ^Scurrent FORTRAN^T may not be correct in future. Proposed text: Replace ^Scurrent FORTRAN standard^T with the correct dated reference and include in clause 2. Seq no: 42 Clause: 4.1.3.4 Kind: English Problem: Proposed text: Insert ^Sa^T after ^Sassumes^T, ^Sfor presentation^T after ^Sterminal^T, replace ^Swith^T with ^Sas^T, insert ^Sor octet length^T after ^Sbyte length^T, replace ^Salso should...test^T with ^Sshould also provide functionality to determine^T, insert ^Sthat^T before ^Swill^T Seq no: 43 Clause: 4.1.3.4.2 Kind: English Problem: Proposed text: Insert ^Sthe^T before ^Smeans^T Seq no: 44 Clause: 4.1.3.4.3 Kind: English Problem: Proposed text: Replace ^Sa^T be ^Sthe^T Seq no: 45 Clause: 4.1.3.4.3 Kind: Minor technical Problem: Example in definition. Proposed text: Move second sentence into a Note. Seq no: 46 Clause: 4.1.3.6 Kind: English Problem: Proposed text: Insert ^San^T before ^Sextended^T 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. Seq no: 48 Clause: 4.1.3.6 Line: Note 1 Kind: English Problem: Proposed text: Replace ^Sought not to^T with ^Sshould not^T, ^Sshould should^T with ^Qshould^T and delete ^Sbut not so strongly recommended^T 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 seuquences 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 Seq no: 50 Clause: 4.1.3.6 Line: Note 2 last line Kind: English Problem: Proposed wording: Insert ^Sand from^T after ^Qto^T (twice) 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 ^Sstandard should provide^T with ^Sstandard committee should consider the provision of^T Seq no: 52 Clause: 4.1.3.7 Kind: English Problem: Proposed wording: Insert ^Sthe^T after ^SIf^T, ^Sa^T before^Tmulti-byte^T, replace ^Scharacter,^T with ^Scharacters,^T, ^Sfunctionalities:^T with ^Sfunctionality:^T Seq no: 53 Clause: 4.1.3.7 Line: a) Kind: Minor technical Problem: Over specifies guideline. Proposed wording: Delete ^Smulti-octet^T 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 Seq no: 55 Clause: Annex A Line: para 3 Kind: Specification too restrictive. Problem: Proposed wording: Insert ^Sminimal set of^T after ^Srecommended^T Seq no: 56 Clause: Annex D Kind: Minor technical Problem: Doesn^Rt seem to be relevant Proposed wording: Delete, but include reference in Note in 4.1.3.6 Seq no: 57 Clause: Annex D Kind: Minor technical Problem: Not relevant and not suited for a Technical report Proposed wording: Delete 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. Seq no: 59 Clause: Several Kind: Minor technical Problem: Usage of FORTRAN inconsistent Original references to "FORTRAN" were to the then standard, that is Fortran 77. Some of the references are no longer true if "FORTRAN" is read as "Fortran 90". This could have been rectified by adding a note in the introduction. However some new text, for example at the top of page 10, uses "FORTRAN" in the sense of "Fortran 90" and refers to facilities not present in Fortran 77. Proposed text: None - WG20 needs to give this attention, even if only minimal clarification. Seq no: 60 Clause: Several Kind: Minor Problem: Examples refer to various languages, but no reference is included in Clause 2. Proposed text: Clause 2 to include ALL references to other standard, even if only mentioned in examples. Seq no: 61 Clause: 3.6.12 Editor's note: Kind: Minor Problem: Proposed text: "EQU" should be "EQUIVALENCE". (This will probably be deleted, but could turn into substantive text.) Seq no: 62 Clause: 4.1.3.1.1: Note 4 Kind: Minor Problem: looks out of place given the now extensive treatment of characters. Proposed text: Delete Note Seq no: 63 Clause: 4.1.3.3.3, last line: Kind: Minor Problem: Proposed text: "permit" should read "define". ---------------------end of document SC22 N2163--------------------