============== Brain's comments ========================================= Seq. no. = BLMEEK-1 Clause: (General) Line: ?? Kind: Editorial (?) Problem: Absent change bars I have noticed that there are changes in the draft which are not accompanied by change bars. I particularly noticed this in clause 3, where a restructuring has taken place without acknowledgement by change bars. This is worrying, since there is no way of checking, apart from detailed word by word comparison, how much this has been done. Unacknowledged changes, including by mistake, are therefore possible. Proposed text: Include change bars in the PDTR for EVERY change from the first edition of the TR ## Proposed disposition: Accepted (may still unmarked points are remained ## by Mistake) ## Editing work: Now under checking Seq. no. = BLMEEK-2 Clause: (General) Line: many Kind: Editorial Problem: punctuation The abbreviation "e.g." does not need a comma after it, and it overdoes the punctuation to include one Proposed text: Delete comma wherever it appears immediately after "e.g.". ## Proposed disposition: Accepted ## Editing work: Done (WD5.1) Seq. no. = BLMEEK-3 Clause: 0. Introduction Line: 4 Kind: Editorial Problem: Updating text If the first paragraph is updated (which is sensible) then the second paragraph needs it also, especially given the phrase "The time is now right". Proposed text: Replace paragraph by something like The first edition of this Technical Report was produced during the 1980s to put together some of the experience that had been gained to that time, in a set of guidelines, designed to ease the task of drafting committees of programming language standards. This second edition enhances the guidelines to take into account subsequent experiences and developments in the areas of internationalization and character sets. ## Proposed disposition: Accespted ## Editing work: Done (Used the above proposed text as is) (WD5.1) Seq. no. = BLMEEK-4 Clause: 0. Introduction/The need for guidelines Line: 8 (and also later places) Kind: Editorial Problem: Use of "language" Here and in some later places the word "language(s)" (here and elsewhere plural) has been gratuitously replaced by "programming language(s)". I believe that in making this tinkering with the original text in places not relevant to the mandated update, WG20 is exceeding its remit from SC22. The use of "language(s)" to mean "programming language(s)" was not done unthinkingly in the original, but deliberately, to make the guidelines easier to read and to accord with common practice in the programming language community. I can appreciate that WG20 may wish later to discuss natural languages as well as programming languages, e.g. in connection with cultural conventions, but this is only in a limited part of the document and is no excuse for modifying the text more widely, in areas not covered by WG20's remit. (It has not even been done consistently, anyway, from line 2 of the introduction onwards!) Proposed text: reinstate original text in all places where this change is made. If necessary, make the distinction between natural languages and programming languages in clauses which need it. If REALLY necessary, add something like this, e.g. after line 3 of the introduction: In this Technical Report, the word "language", unless otherwise qualified, means "programming language", not "natural language", in accordance with common practice in the programming language community. In most cases, this will anyway be clear from the context. ## Proposed disposition: Rejected ## The addition of "programming" immediate before the ## "language" is not to distinguish programming language ## form natural language, but just for consistency. ## In many places of the original TR, programming ## language or programming language standard are fully ## spelled out, but in a few places, they are referewd ## by just "language" or "the standard". To use ## consistent wording by keeping the original text as ## far as possible, the addition of "programming" is ## choosed rather than replacement of all the " ## programming anguage" with "language" and "programming ## language standard" with "the standard". ## original text as far as p ## Editing work: No action taken Seq. no. = BLMEEK-5 Clause: 0. Introduction/The need for guidelines Line: second from last of this subsection Kind: Editorial Problem: unnecessary wording change: "extra efforts" The original wording is perfectly satisfactory (and is better expressed than "extra efforts", which is not usual English usage) and is another piece of gratuitous tinkering which goes beyond WG20's remit from SC22. Proposed text: reinstate original text. ## Proposed disposition: Accepted ## If US national body stick the wording of ## "extra effort", please comments to this ## item again. For the time being, the wording ## is restored to original "an immens extra ## burden". ## By US national body (Antoni) ## Editing work: Done (WD6.0) Seq. no. = BLMEEK-6 Clause: 0. Introduction/How to use... Line: 8-10 Kind: Editorial Problem: unnecessary wording changes This instance of gratuitous tinkering is a special case of BLMEEK-4 but the additional changes - which seem to add nothing worthwhile - have completely garbled the sense: "the not adopting guidelines and its reasons may be taken into account" is extremely hard to understand [though it can be, with "extra effort" (!)]. The rest, after the "when", has no verb; when the revision is .... what? The result does not make sense and is much harder to read and understand than the original, which seems in no need of change even if it were within WG20's remit to do so. Proposed text: reinstate original text. ## Proposed disposition: Partially accepted. ## The new proposed text is ## Reasons for not adopting any particular guideline ## should be documented and made available, ## (e.g. in an informative annex of the ## programming language standard). This and the ## reason therefore can be taken into account at ## future revisions of the programming language ## standard or technical report. ## Editing work: Done (WD5.1) Seq. no. = BLMEEK-7 Clause: 0. Introduction/Further related guidelines Line: 4-5 Kind: Minor technical Problem: update needed The sentence beginning "At the time of publication" and referring to "existing or forthcoming Technical Reports" needs to be reconsidered in the light of subsequent developments Proposed text: Nothing specific to propose: I suggest WG20 reviews the current state of TRs and modify this sentence accordingly. You may also was to add to the "See in particular" references at the end. ## Proposed disposition: Should be discussed in the WG20 ## Editing work: No action right now Seq. no. = BLMEEK-8 Clause: General Line: Kind: Editorial Problem: change to two column format The format has been changed from one to two columns, which makes it harder to compare versions when changes are small or are not (supposed to be) made. WG10 thought for this kind of document one column was more readable than two, and ITTF then thought that was OK. Why change? Proposed text: Revert to one-column format (unless ITTF now require two even for TRs) to aid comparison between editions ## Proposed disposition: Accepted ## Editing work: Done (WD5.1) Seq. no. = BLMEEK-9 Clause: 2. References Line: various Kind: Editorial Problem: ordering of items New references seem to have been put in at random regardless of number Proposed text: Make the references in strict numerical order of ISO or ISO/IEC numbering, followed by any other (in this case only the one). ## Proposed disposition: Accepted ## Editing work: Done (WD5.1) Seq. no. = BLMEEK-10 Clause: 3. Definitions Line: various Kind: Editorial Problem: destruction of substructure of clause In the original TR the definitions were deliberately grouped under subheadings, as an aid to the reader (and ITTF had no objection). This structure has been destroyed, leaving a flat list. Making such a change is outside the remit of WG20, and harms the readability of the document: for example, the definition now numbered 3.6 (formerly 3.3.4) makes no sense in a lfat list since it belongs to the old group 3.3. There will be a problem of making 3.6 seem sensible unless the substructure is restored. Proposed text: Restore substructure, with the headings reinstated that have been removed (without change bars); create a new subclause 3.6 for characters and make the new 3.11-3.21 3.6.1 to 3.6.11 (though not in the same order, see later) ## Proposed disposition: Accepted ## Editorial work: Done (WD6.0) Seq. no. = BLMEEK-11 Clause: 3.1 Note 2 Line: 1,2, and 7 Kind: Editorial Problem: designation of ISO TR A space has intruded between ISO and /TR in 3 references to 9547. The first edition had no space. However, I suspect that the / in the original was an error, and that an ISO TR should be shown e.g. ISO TR 9547 Proposed text: check with ITTF on correct designation and make these references (and others, e.g. in clause 2) accord with that ruling. ## Proposed disposition: Accepted ## Editing work: Done (WD5.1) Seq. no. = BLMEEK-12 Clause: 3.7 Note 1 editor's note Line: Kind: minor technical Problem: proposed change This note suggests the US were putting forward a change to this note. In that this is an example, a change here would be outside the remit of WG20 despite it being about collation. The original Note 1 makes a statement of fact. It carries no implication whatever about the nature of collating - there might be none at all. That's what 'processor-dependent' means, and how anyone could imagine it carries some assumption about its nature is beyond my understanding. The editor is quite right that there is no problem with the current wording. Proposed text: leave it as it is. ## Proposed disposition: Accepted ## If US national body still has any problem on the ## text, it will be appreciate if US can submit ## their comments again with rationale. ## Editing work: Remove Editor's note ## Done (WD6.0) Seq. no. = BLMEEK-13 Clause: 3.11-3.21 Line: various Kind: editorial Problem: missing stops The definitions do not end with full stops, which is inconsistent with the previous ones. Proposed text: put in the full stops ## Proposed disposition: Accepted ## Editing work: Done (WD5.1) Seq. no. = BLMEEK-14 Clause: 3.11-3.21 Line: various Kind: editorial/?minor technical Problem: lack of explanation and discussion As an informative, guidelines TR, the definitions would be helped by explanatory discussion in most if not cases, as with the earlier definitions. This TR is to explain and inform, and it's important to do this for definitions, rather than just list them as one might for a more formal normative document. Proposed text: add explanations and discussion where needed (most if not all definitions) ## Proposed disposition: Rejected ## "The explanations and discussion where needed" is ## not requested by ISO Directive part 3. And such ## style is not so common across ISO standard nor ## TR, although the first edition of the TR adopted ## the style. This comment should be discussed in ## WG20 meeting. ## Editing work: No action taken Seq. no. = BLMEEK-15 Clause: 3.11-3.21 Line: all Kind: editorial Problem: ordering The ordering of the new definitions is illogical and confusing for the reader. Proposed text: change the order of these items as follows: 13,19,12,17,11,18,16,20; I'm not sure where 21 belongs, see later. ## Proposed disposition: Partially Accepted ## Reorder them by using alphabet order ## Editing work: Done (WD5.1) Seq. no. = BLMEEK-16 Clause: 3.11 Line: all Kind: editorial Problem: wording The wording could benefit from improvement. Proposed text: change to: A character set that is common across every execution environment, e.g. the invariant set of ISO/IEC 646. ## Proposed disposition: Accepted ## Editing work: Done (WD5.1) Seq. no. = BLMEEK-17 Clause: 3.12,13,19 Line: various Kind: editorial/minor technical Problem: lack of explanation and discussion These definitions very much need explanatory discussion as suggested under BLMEEK-14. The differences between these three need very careful explanation for the likely readership of the TR, and plain definitions are not sufficient. Note that the editor feels a note is needed here for review purposes, though the point made appears later (too late, I suspect) in 4.1.3.7.1. Proposed text: add explanations and discussion of the distinctions between the three concepts. ## Proposed disposition: Accepted ## Editing work: Doing on (WD6.0) ## Comments to the new definitions are required. Seq. no. = BLMEEK-18 Clause: 3.12 Line: Kind: editorial/minor technical Problem: relation to octet Is it really true that bytes are larger than octets, but can't be smaller? The time of EBCDIC is past (I think and hope) but there was a time when 6-bit bytes were talked about. This is a point for explanation, but I am also asking for assurance about the accuracy of the statement. Proposed text: check and clarify! ## Proposed disposition: Accepted ## Editorial work: Delete the sentense of "equal to or larger than 8 ## bits". Done (WD6.0) Seq. no. = BLMEEK-19 Clause: 3.15 Line: 2,3 Kind: editorial/minor technical Problem: what is a "native" language? A user may be required to use a natural language which is not her or his "native" language. When in France I use a natural language which is not my native language. "natural" is surely what is meant here. If it is thought this might confuse, "human" language might do, though less usual. Proposed text: change "native" to "natural" (2 places). ## Proposed disposition: Consistent definition with PDTR 11017 ## will be used. So the definition will be ## rewritten. It does not use ``native language''. ## Editing work: Done (WD5.1) Seq. no. = BLMEEK-20 Clause: 3.17 Line: Kind: editorial/minor technical Problem: obscure and dubious definition I don't understand this. For a start "units" is plural sor you can't have "a sequential units" of anything. And (this is where it gets harder) what is a "unit" of a datatype? I presume what is meant is a "sequence" of something (what?) - but what does it matter (for virtually all languages) that this (whatever it may be) is how thing are STORED? Logical sequences maybe, but storage is at a representational level which languages, other than low level implementation languages, should not normally concern themselves with. Proposed text: I wish I knew! Certainly a lot different! ## Proposed disposition: Accepted ## Editorial wrok: Currently the definition is modified as ## ``A coded character stored in a set of multiple ## units in an array of basic character data type. ## The set must be in a continuous range in the ## array."" ## The above definition should be discussed in WG20. ## The concept of multi-byte (form of) character ## is introduced by C language and POSIX. ## Editing work is tentatively done (WD5.1) Seq. no. = BLMEEK-21 Clause: 3.17, 3.18 and later Line: 2 of 3.17 Kind: editorial/minor technical Problem: spelling of "datatype" "datatype" is better spelt without the space. It is not just editorial - the point is that a datatype is more than just a type of data, and leaving the space out stresses that it is an entity in its own right. It's particularly important with character datatypes, which have careful distinctions between values as concepts, codes, appearance etc. Proposed text: replace "data type" by "datatype", here and throughout. ## Proposed disposition: Rejected ## Original text, the first edition of TR 10176, ## put a space between data and type. ## see item b of 4.1.5.1.3 of the first edition. ## Editing work: No action Seq. no. = BLMEEK-22 Clause: 3.19 Line: 1 Kind: editorial/minor technical Problem: ordered There's a lot of confusion about ordering, and this is perhaps the place to explain that, though the bits in the octet may be ordered (so that 01010101 is not the same as 11110000) this does not imply an ordering of the octets themselves. It ought not to need saying, but WG11 found when handling comments on 11404 LID that people got surprisingly confused about (say) the ordering of array elements by their index and the ordering of the values of the elements themselves! Proposed text: add suitable explanation ## Proposed disposition: Proposed text is wanted. ## Who can provide the text? ## Editing work: No action right now. Seq. no. = BLMEEK-23 Clause: 3.21 Line: all Kind: technical Problem: incomprehensible definition I can't understand this at all and I've tried several times. What is it supposed to be? a "code" (singular) can't "are" (plural) anyway but correcting it either way doesn't help. A code "stored in/on a file system"? What does it mean? Why is this needed? (Maybe why it's needed will become clear, I don't know, but it won't help if I don't know what it is!) I have done a search of the new text, looking for use of the term, but can't find any use of it. Proposed text: delete 3.21 (assuming this term is not used in the revised TR). Otherwise replace by a new definition that can be understood. ##Proposed disposition: Accepted ##Editing work: Done (WD6.0). Seq. no. = BLMEEK-24 Clause: 4.1.1 k) and l) Line: general Kind: technical Problem: doubtful new subclauses These look like further gratuitous additions to the TR which are outside the remit of WG20 to include; they do not seem sufficiently tied in to the internationalisation aspects which ARE Wg20's remit. I yield to none in my devotion to user requirements in standards but this reference to it is meaningless: the user requirements from a language standard are a complete and precise definition of the syntax and semantics, plus the conformity rules regarding properties of implementations and programs. These guidelines themselves embody the user requirements. If an annex is needed in a standard it's more likely to be to say what user requirements that ought to be in the standard are in fact not! In short, it's quite unclear what a committee would put in such an annex, that wouldn't already be in the scope and conformity clauses. As for portability, the intent of this was (in WG10's mind) covered by subclauses e) and f), and loading further annexes to cover the same ground seems quite unnecessary. Proposed text: remove these new clauses. If WG20 are reluctant to do this then they should first give a proper justification for them in terms of what they would cover which isn't already covered, AND in addtiion get a ruling from SC22 that making such additions is within their remit in this revision. ##Prposed disposition: Rejected ## Although those items are out of WG20's scope as ## commented, those two items are comes from JTC1 ## resolution based on the JTC1/TSG-1 recommendation ## described in their final report. Since JTC1 ## directed to all standard development WG under ## JTC1 to provide those 2 annexes, it is appropriate ## for TR 10176 "Guidelines for the preparation of ## programming language standards" to mention about ## the JTC1 direction. ##Editing work: Add an editor's note and describe that those ## guidelines come from JTC1 resolution. Seq. no. = BLMEEK-25 Clause: 4.1.3 Line: general Kind: technical Problem: organisation of clause The additional material added (rightly) by WG20 has placed a strain on the organisation of the document inherited from WG10. The first example comes under the old 4.1.3.1 when added a second guideline has necessitated an extra subheading so we have both 4.1.3.1 Character "sets" used for program text and 4.1.3.1.1 Character "repertoire" used for program text. I think many readers will be confused by this. Proposed text: Revise the substructure of 4.1.3 to have a new 4.1.3.1 "Guidleines on character sets used in program specifications" with a new paragraph explaining that this means the source code and that this covers the program text proper, user-defined identifiers, character literals, and comments. Then have the related guidelines grouped underneath it: 4.1.3.1.1 (with "sets", not "repertoire"), 4.1.3.1.2, 4.1.3.1.3 (the present 4.1.3.3), 4.1.3.1.4 (the present 4.1.3.2), 4.1.3.1.5 (the present 4.1.3.4). Make a new 4.1.3.2 "Guidleines on character sets used for data and program execution" and then group the data-related guidelines under that. You may want to create a new 4.1.3.3 to contain the MOCS-related guidelines separately. ##Proposed disposition: Accepted ##Editing work: Done (WD6.0) Seq. no. = BLMEEK-26 Clause: 4.1.3.1.1 Line: 9-13 Kind: editorial Problem: muddled wording introduced by unnecessary change Since the guideline is about using 646 there was no need to alter this sentence since it can only relates to the non-printing characters of 646, not any others. The result of changing is to leave the text garbled. Proposed text: revert to original. If WG20 thinks that it does need the repetition of "of 646" (which it doesn't!) then instead put: Great care should be taken in specifying how the ``non-printing'' characters of ISO/IEC 646 [OR: "of the ISO/IEC 646 coded character set", if you really must make a meal of it!] are to be handled, i.e. those characters that correspond to integer values 0 to 32 inclusive and 127, i.e. null (0/0) to space (2/0) and delete (7/15). ##Proposed disposition: Rejected ## The main part of this guideine only interests in ## ``non-printing'' character set. The code points of ## each non-printing character is not matter of ## the guideline. However, in the example, code ## point of the characters are presented. Since the ## code points may vary from coded character set ## to another, regardless of if the subject character ## itself is in the repertoire of ISO/IEC 646. Therefore ## it should be noted that the presented code point of ## each character is the one that is an example refering ## to ISO/IEC 646's code table. ##Editing work: No action taken Seq. no. = BLMEEK-27 Clause: 4.1.3.1.1 Note 1 Line: 6-7 Kind: editorial/minor technical Problem: is ASCII=IRV? Is it really the case that in 646:1991 IRV and ASCII are identical, in every respect? I thought it used not to be, which is why the first TR was worded this way. If it is, then fine, though I'd suggest a minor wording improvement. Proposed text: depending on the answer to the query, EITHER revert to original text, or reword as follows .. International Reference Version of ISO/IEC 646 (equivalent to the U.S. national variant, usually referred to .... "identical" might be even clearer than "equivalent" - if true! ##Proposed disposition: Rejected ## In the timeframe of 1991, IRV of ISO/IEC 646 is not ## identical with ASCII. However, at the latest revision ## of the internatioanl standard, the code table of the ## ISO/IEC 646 has become identical with ASCII. ## It can not be said that whole wording of ISO/IEC 646 ## is identical with ASCII, the word ``equivalent'' is ## used in this TR. ##Editing work: No action taken. Seq. no. = BLMEEK-28 Clause: 4.1.3.1.1 Note 2 Line: 3-4 Kind: editorial Problem: awkward wording Proposed text: revise to read ... character sets ISO/IEC 4873 with ISO/IEC 8859-1, or ISO 6937-2, would be sufficient to represent programs in a way that, in Western European and American cultures, looks familiar to most (but not APL) programmers. ##Proposed disposition: Accepted ##Editing work: Done (WD6.0) Seq. no. = BLMEEK-29 Clause: 4.1.3.1.1 Note 3 Line: 3-4 Kind: editorial Problem: awkward wording Proposed text: revise to read The characters that are available in the sixteen or thirty one-bit coded character sets of ISO/IEC 10646-1 would be sufficient to represent programs in a way that looks familiar to most programmers from most cultures. However, in \theyear\ this standard is not yet widely supported on printers and display terminals. ##Proposed disposition: Accepted ##Editing work: Done (WD6.0) Seq. no. = BLMEEK-30 Clause: 4.1.3.1.2 Line: 3-4 Kind: editorial Problem: awkward wording Proposed text: revise to read Guideline: Identification of characters used for program text The standard should provide an annex containing a correspondence table between the graphic representations of the characters used for program text in the standard, and the character identifiers specified by ISO/IEC 10646. NOTE - It is possible to write program text using a character set that includes characters whose shapes are identical or very similar to one another. For example, in ISO/IEC 10646-1, the capital letter A of the Latin, Greek, and Cyrillic alphabets have identical shapes. Also, ISO/IEC 10646-1 specifies many ``non-printing'' characters that occupy a certain amount of space in the presentation of text. Therefore, if a language standard specifies a character used for program text only by using its graphic shape, it is ambiguous whether this shape means any of the characters that have the same or a similar shape, or a particular one of them (e.g. only the Latin alphabet 'A' in the above example). Adoption of this guideline avoids such ambiguity. ##Proposed disposition: Accepted ##Editing work: Done (WD6.0) Seq. no. = BLMEEK-31 Clause: 4.1.3.2 Line: 19-21 Kind: editorial Problem: awkward wording I am not sure whether there is some clash between ``as themselves'' and "as ``extended character'' literals" but assuming there is not: Proposed text: revise to read Any conforming processor should be required to be able to accept ``as themselves'' [i.e., as in \ref{char:lite:e1}], but as ``extended character'' literals, all printable characters in the ISO/IEC 10646-1 character set. ##Proposed disposition: Accepted ##Editing work: Rewite the subject sentense and add editor's note ## to clarify the intention. ## Done (WD6.0) Seq. no. = BLMEEK-32 Clause: 4.1.3.3 Line: 19-21 Kind: editorial/minor technical Problem: imprecise wording What is being talked about here are USER-DEFINED identifiers; other identifiers used e.g. as keywords or names of built-in procedures are already covered by "program text" Proposed text: revise title to Guideline: Character sets used in user-defined identifiers ##Proposed disposition: Accepted ##Editing work: Done (WD6.0) Seq. no. = BLMEEK-33 Clause: 4.1.3.3 Line: all Kind: editorial Problem: awkward wording Proposed text: revise to read The standard should define which, and in what way, characters outside the ``minimal'' set defined in \ref{char:prog-t} can be used in user-defined identifiers. If a variant of ISO/IEC 10646 is permitted, then the characters listed in annex \ref{ext-ident} should be allowable. \begin{notes} \item{ It is important to allow characters from outside the Latin alphabet to be used in identifiers in program text, to improve understandability for programmers whose native language is by not English. \item Allowing an extended character repertoire to be used for identifiers may have an adverse effect on the portability of the application concerned. A possible solution to this portability problem is proposed in Annex \ref{UCS-sol:ident}. ##Proposed disposition: Accepted ##Editing work: Done (WD6.0) Seq. no. = BLMEEK-34 Clause: 4.1.3.4 Note Line: 5 Kind: editorial Problem: unnecessary added word What is the point of changing "portability" to "application portability"? It says absolutely nothing - programs are virtually by definition applications, and anyway the context makes this clear. Is it because it's a common buzzphrase these days? Proposed text: revert to original text ##Proposed disposition: Accepted ##Editing work: Done (WD6.0) Seq. no. = BLMEEK-35 Clause: 4.1.3.5 Line: header Kind: editorial Problem: 4.1.3.5 is now NOT a guideline, it's a header introducing a number of guidelines. Proposed text: See BLMEEK-25 for a way round this. ##Proposed disposition: Accepted ##Editing work: Done (WD6.0) Seq. no. = BLMEEK-36 Clause: 4.1.3.5 Line: 8-9 Kind: editorial Problem: awkward wording Proposed text: revise to read The standard should also specify whether, and in what way, support for ISO/IEC 10646-1 is required to be provided. ##Proposed disposition: Accepted ##Editing work: Done (WD6.0) Seq. no. = BLMEEK-37 Clause: 4.1.3.5.2 Line: 1 Kind: editorial ++ Problem: ambiguous wording This reads "A programming language standard MAY provide..." (my emphasis). .4 and .5 show the same form. What does the MAY mean? A statement of fact? A statement that it is permitted? If so, what is the guideline? I assume that the guideline is that a p.l. SHOULD do this, in which case it should say so. Proposed text: replace "may" by "should", or else reword to clarify intended meaning. Do the same in 4.1.3.5.4 and 4.1.3.5.5. ##Proposed disposition: Accepted ## Clarifiy the usage of "shold" and "may" in the ## definition section. ##Editing work: Done (WD6.0) Seq. no. = BLMEEK-38 Clause: 4.1.3.5.2 Line: 1-4 Kind: technical (minor??) Problem: confused wording This reads "... a character data type that is large enough to store every basic character but not large enough to store every character in an extended character set in a unit of the data type, i.e., basic character data type." What does a datatype being "large" or "small" mean? How can a datatype "store" anything? (Machines do that.) What's a "unit" (see BLMEEK-20). I assume that the idea is that the cardinality of the datatype (i.e. number of distinct values) is sufficient for all the character values of the basic character set (and maybe more) but not for all the character values of the extended character set. But you need more than just the cardinality, surely, you need the values of the datatype actually to BE the charcter values? If that's what you mean, why not say so? If it isn't, I haven't a clue what you mean! Proposed text: revise to read "... a character datatype whose constituent values include all the characters of the basic character set but not all the characters of the extended character set." perhaps with a note to say that this is what you mean by "basic character datatype". ##Proposed disposition: Accepted ## [Editor's note] Thanks for fine definition!! ##Editing work: Done (WD6.0) Seq. no. = BLMEEK-39 Clause: 4.1.3.5.2 Line: 5-8 Kind: editorial/technical (minor??) Problem: confused wording This once more begins with a "may" and in this case I think it really is one. If so it is not part of the guideline but is a note to the guideline. It could do with some wording tidying too. It's still a bit unsatisfactory though, since the earlier part implied that the basic character dataype could include extra values above the basic set, whereas this seems to imply that values outside the basic set can only be represented in some so-called "multi-byte" (itself begging the question of the distinction between a byte and a character; and don't you need a reference to escape sequences?). You may want to rethink this whole aspect. I know I would; but then I may not be understanding it correctly. Proposed text: revise to read "Note: The standard may allow the use of the basic character datatype to represent a wider range of characters, from outside of basic character set, by means of a sequence of values of the basic character datatype." ##Proposed desposition: Accepted ##Editing work: Done (WD6.0) Seq. no. = BLMEEK-40 Clause: 4.1.3.5.3 Line: all Kind: editorial/technical (minor??) Problem: I don't understand what this means. Is it that, regardless of basic and extended sets, if a particular environment has a particular set/repertoire available there should be a datatype whose value-set (presumably implementation and execution-context dependent) is exactly and precisely those characters available there, and no others? Is this a useful concept? Is it an advance on what we have now? Proposed text: no idea, but not this. ##Proposed disposition: Accepted but no action. ## Some implementation of programming language ## actually support wider range of character ## by using multi-byte form. The reason to ## provide this guideline is to insist that ## extended character data type is the ## recommended way to support those wider range ## of character, then all of programming ## language standard should provide this ## data type at least. The multi-byte method ## is optional one, but it should be prohibitted ## to provide only multi-byte method without ## extended character data type support. ##Editing work: No action. Seq. no. = BLMEEK-41 Clause: 4.1.3.5.4 Line: all Kind: editorial (+?) Problem: Awkward wording, including some points raised earlier (e.g. "store"), plus typos, and first sentence isn't a guideline. Proposed text: Should the standard define or make provision for the declaration of subtypes of the character datatype, or for multiple character datatypes, then it should also explicitly address all relevant questions of the use of mixed character datatype, including assignment of the value of one character datatype to a variable of another, comparison between values of different character datatypes, etc. Note: {\bf kind$=$n} in the Fortran 9) standard is an example of this kind of multiple facility. ##Proposed disposition: Rejected ## The intention of this guideline is permission of ## of inter character (sub-) data type assignment ## and comparison. The guideline is only apprecable ## for the langauge that provide multu-ple character ## (sub-) data type. Therefore, the first sentense ## is presented as condition of the guideline. ##Editing work: Slightly modofied. (WD6.0) Seq. no. = BLMEEK-42 Clause: 4.1.3.5.5 Line: 2-3,4-6 Kind: minor technical Problem: What IS a "character cell terminal"? Why should it matter to a p.l. standard what the "presentation width" is, and what's it got to do with "byte lengths"? At the level of definition of a language, these things should not matter, surely? If it does matter, there's something wrong with the standard. (Or the language.) Proposed text: no idea; personally I'd delete the whole guideline. ##Proposed disposition: Rejected ## Most of programming language does not have ## presentation services, but COBOL has. That is ## REPORT WRITER. Usually Asian Ideographs takes ## 2 columns on fixed width font presentation space, ## though Latin alphabet only takes one column. ## This guideline is for programming langauge ## that has presentation service. ##Editing work: No action taken on the subject clause, but ## add definition of character cell terminal and ## presentation width. Done (WD6.0) Seq. no. = BLMEEK-43 Clause: 4.1.3.5.6 Line: all Kind: minor technical Problem: What is a "class"? Should the term not be defined? Surely they are just subtypes of the datatype, each one recognised by just one operation of its own, namely a "belongs" op for each on the character datatype, yielding True or False. The word "class" is used much more specifically in other contextx, and should be avoided here to reduce the risk of confusion. Proposed text: The standard should include means of testing whether a given character value belongs to subsets of the character datatype likely to be of importance in applications, such as alphabetic, alphanumeric, upper case letters, lower case letter, decimal digit, hexadecimal digit, control character, punctuation character, printable character, graphic character, space character The standard should require that the means supplied does not depend on a specific coded character set, and may require, or permit, the provision of such means of testing for further subsets that are culture-specific or (human) language-specific. [What about application-specific?) ##Proposed disposition: Accepted ##Editing work: Done (WD6.0) Seq. no. = BLMEEK-44 Clause: 4.1.3.5.7 Line: all Kind: technical Problem: By "transliteration" you mean "mapping", I assume. You refer to "equivalent character semantics", but who decides that they ARE equivalent? I contend, only the application programmer. Even in the same application, lower/upper case my be equivalent in some contexts, not others. OK, it's the programmer's choice whether to invoke this mapping or not, but for some applications what's needed is so specific to that context that no standard can anticipate it. Isn't what's needed a means for the programmer to specify that certain character values can, for such-and-such purpose, be deemed equivalent (or, all mapped onto a single "canonical" value)? I suspect this may be going too far in the direction of language design. There may be a case for a simple yes/no over whether upper/lower case are distinguished or not, and hence a guideline saying that the committee should consider whether or not to include such a this, but a guideline going beyond that seems to me unnecessary. Proposed text: Delete the guideline (preferred) or if included be confined to upper/lower case in the way just outlined. ##Proposed disposition: Rejected ## Clarify the functionality is just for ## apprication program not for parsing of ## program text. ##Editing work: Add notes Done (WD6.0) Seq. no. = BLMEEK-45 Clause: 4.1.3.6 Line: 1 Kind: editorial Problem: This is now a header, not a guideline. Proposed text: change to read "Guidelines on collating sequences" ##Proposed disposition: Accepted ## Restructured the clause then removed its ## subcluase, then the title of the clause ## becomes real guideline. ##Editing work: Done (WD6.0) Seq. no. = BLMEEK-46 Clause: 4.1.3.6.1 and .2 Line: 1 in each case Kind: editorial Problem: These are guidelines, so call them that. Proposed text: Insert "Guideline:" before "ISO/IEC" in each case. ##Proposed disposition: Rejected ## Since the subclause has been removed, ## this comment becomes not appricable. ##Editing work: Done (WD6.0) Seq. no. = BLMEEK-47 Clause: 4.1.3.6.2 Line: 7-9 Kind: editorial Problem: difficult wording Proposed text: The standard should require that the collating sequence character sets based on ISO/IEC 10646-1 shall be that defined in {WG20 reference}. [NB the WG20 should have an ISO number as soon as registered and so the current project number shouldn't be used. ITTF will require something other than this anyway - BLM] ##Proposed disposition: Accepted ##Editing work: Done (WD6.0) Seq. no. = BLMEEK-48 Clause: 4.1.3.7 Line: all Kind: technical Problem: This has got very confused. It isn't clear now what "other" means in the header; maybe something like "Use of a range of.." might now be better. There is also serious confusion (to me) between the three levels of abstraction represented by character octet byte a point I have made earlier. I simply don't understand what the new final sentence of this guideline (lines 5-6) is supposed to mean, even after deleting the duplicate "by". Proposed text: No idea but it needs fixing. The original sentence can probably stand (replacing the new "Programming language" at the start by "The" of course). The problem is in what you want to add, which at present simply makes what came before obscure. ##Proposed disposition: Rejected (right now) ## The clause is restructured. ## Add definition of byte, octet, characters .... ##Editing work: Done (WD6.0) Seq. no. = BLMEEK-49 Clause: 4.1.3.7 Note 2 Line: 6/7 Kind: editorial/technical? Problem: extra five words at end. They appear to have strayed in formo somewhere, there's no capital letter at the start. It is not marked by change bars. Is it intended to be added, or not? If so it sounds like a note to add something which hasn't been carried out. Proposed text: delete, or if something is intended, rewrite it so that it makes sense at the end of this note, e.g. normalization of what? required for what? and why needed? ##Proposed disposition: Accepted (simple editing error) ## Editing work: Done (WD6.0) Seq. no. = BLMEEK-50 Clause: 4.1.3.7.1 Line: all Kind: editorial/technical? Problem: How can this come under 4.1.3.7, which is a guideline? Proposed text: Maybe 4.1.3.7 should be turned into a header and the guideline itself numbered .1, renumbering the rest, but it looks to me as though this one should be numbered 4.1.3.8. 4.1.3.7.2 should become 4.1.3.9. ##Proposed disposition: Accepted ## The whole related clause has been restructured. ##Editing work: Done (WD6.0) Seq. no. = BLMEEK-51 Clause: 4.1.3.7.1 Line: all Kind: editorial Problem: poor wording Proposed text: revise to read as follows: The standard should provide for an extended character datatype whose values form an extended character set representable by a multiple-octet code. The standard should ensure that at least every character specified by ISO/IEC 10646 is a value of this extended character datatype. Note 1. The standard does not need to require that a combining or conjoining sequence of ISO/IEC 10646 be recognized as a single character. Each character in a combining or conjoining sequence should constitute a separate value of the extended character datatype. Note 2. A standard may specify functionality to test the boundary of a combining or conjoining sequence and to convert the combining or conjoining sequence into the corresponding pre-composed character. Alternatively, it may specify a datatype whose values include combining or conjoining sequences of characters, and provide functionality to convert a character string to a value of this datatype or to a string of this datatype. ##Proposed disposition: Accepted ##Editing work: Done (WD6.0) Seq. no. = BLMEEK-52 Clause: 4.1.3.7.1 Note 1 Line: 1,4 Kind: minor techical Problem: "does not need to" in line 1 and "should" in line 4, which I have retained in my redraft, seem to imply different things. The first suggests it can but it doesn't have to, in which case what follows advises what it can do instead, but the second implies that this is what it OUGHT to do, i.e. that "does not need to" really means "ought not to". You need to decide which you mean, and say so. To me, it seems the first would be more sensible, but the presence of Note 2 suggests the second - unless Note 2 really continues the advice in the second sentence in Note 1. Proposed text: Without knowing what you mean, I can't suggest any. But is you DO mean "ought not to" in line 1 then it would be best to explain WHY, in a continuation of the note, and then put the second sentence in with Note 2 as advice. If it does mean "it can but it doesn't have to" then the rewording should make clear what the status is of Note 2 in relation to this one. ##Proposed disposition: Accepted ## I intend to say "ought not to recognize as a character" ## therefore out not to store it in a character data type. ## composit sequence is an object other than character, ## then suggest to store it another data type from ## character, if required. ##Editing work: Done (WD6.0) Seq. no. = BLMEEK-53 Clause: 4.1.3.7.1 Note 2 Line: 4 Kind: minor techical Problem: The "or" seems to introduce an alternative course of action, i.e. an "exclusive or", so I've replaced it by "Alternatively" in the redraft, partly to make it clear that this is what's meant, partly because previously the sentence was far to long to be understandable and needed splitting up. However, "or" could possibly mean INCLUSIVE or, i.e. this is another thing you could do, as well or instead. Proposed text: leave as in my redraft if you did mean "exclusive", otherwise revise to make it clear what you did mean. I can't tell from what's there. ##Proposed disposition: Accepted ##Editing work: Done (WD6.0) ========================= Arnold's comments ================================ Page v,-,4: Reasons for not adopting a particular guideline should be documented and made available, e.g. in an informative annex of the programming language standard. This and the reason therefore can be taken into account at future revisions of the programming language standard or technical report. ## Proposed disposition: Accepted except the proposed changes: ## any -> a, and removal of parenthesis. Those are ## first edition of this TR. ## Editing work: Done (WD5.1) Page 1,L,3: Large space between "Information" and "processing" ## Proposed disposition: Rejected ## This is just formatting matter. ## Editing work: No action Page 3, L, 3, Editors note: The above definition originates from ISO/IEC 10646. This ensures that .... Note that a combining sequence of ISO/IEC 10646 is not a character. Each element of a combining sequence is considered a "character" in this TR. (Arnold: You might want to include this explanation in the TR) ## Proposed disposition: Accepted ## Editing work: Done (WD5.1) Page 4, L, 1: exchange "what" by "which" ## Proposed disposition: Rejected ## The statement is originated by TSG-1 final report ## and approved by JTC1. ## Editing work: No action Page 4, R, 4 The 11th guideline does not deal with interchange issues. It ensures that ... ## Proposed disposition: Rejected ## The subject sentense is originated by the first ## edition of TR 10176. ## Editing work: No action Page 5, L, 8 and page 5, R, 1 A program text may be written, using a character set that includes characters with identical or very similar shapes. ISO/IEC 10646 for example contains 3 characters with identical shapes, namely the capital letters A of the Latin, the Greek, and the Cyrillic alphabets.... Therefore, if a programming language standard specifies a character by its shape, it can be unclear which of the characters of identical shape is meant. To avoid such ambiguity, the programming language standard should provide an annex that... (Arnolds note: that will not help, because for the shape of the "A" you would still be able to find 3 different 10646 identifiers.) ## Proposed disposition: Mostly accepted ## Editing work: Done (WD5.1) Page 5, R, 2: (Arnolds note: I think that needs an example, the description is correct, but confusing) ## Proposed disposition: Accepted ## Editing work: Done (WD5.1) Page 6, R,1: The standard should define which characters from outside the "minimal" set defined in 4.1.3.1.1 can be used in identifiers. If ISO/IEC 10646 is permitted, the characters in Annex A should be allowed. (Arnold: what is a variant of 10646?) Note 2: Allowing the extended repertoire of characters for identifiers may impact... ## Proposed disposition: Accepted ## "variant of 10646" is a typo. It is intended to ## be outside of ISO/IEC 646 invariant set. ## Editing work: Done (WD5.1) Page 6, R, 6: ... If a programming language standard provides such functionality, the standard should not assume that the presentation width of a character on a character cell terminal is the same as the length of the character in bytes. ... ## Proposed disposition: Accepted ## Editing work: Done (WD5.1) Page 7, L, 1: The programming .... ## Proposed disposition: Accepted ## Editing work: Done (WD5.1) Page 7, L, 4: The collating sequence supported by the programming language should conform to the international ordering standard IS 14651 that is presently being developed as project JTC1 22.30.02.02. ## Proposed disposition: Accepted ## Editing work: Done (WD5.1) Page 7, R, 2 and L, 3 ...multi-byte forms ... ## Proposed disposition: Accepted ## Editing work: Done (WD5.1) Page 7, R, 4 The programming language standard should ensure that at least... ## Proposed disposition: Accepted ## Editing work: Done (WD5.1) Page 7, R, 4, note 1 The programming ... ## Proposed disposition: Accepted ## Editing work: Done (WD5.1) Page 7, R, 4, note 2 (Arnold: I do not understand the meaning of ...may provide a data to store...) ## Proposed disposition: Accepted ## data should be data type ## Editing work: Done (WD5.1) Page 7, R, 5 ... If the programming language standard supports the multi-byte form of characters, the standard ... ## Proposed disposition: Accepted ## Editing work: Done (WD5.1) Page 8, L, 1 a) Convert the multi-byte form of a character to the extended character form, and vice versa. ## Proposed disposition: Accepted ## Editing work: Done (WD5.1) Page 17, L, 1 The programming language standard should provide the functionality to dynamically switch from one cultural convention set to another (e.g. the setlocale function in C language). If the programming language supports multiple threads in a process, the cultural convention set binding should be done by thread, not by process. ## Proposed disposition: Accepted ## Editing work: Done (WD5.1) Page 17, R, 1 The programming ... ## Proposed disposition: Accepted ## Editing work: Done (WD5.1) ===================================================================== Source: Jon Diamond, Hoskyns Group, UK Status: Expert contribution (MUMPS Development Committee) Date: 1995-08-18 Seq: 1 Clause: 3.7 Line: NOTE 1 Kind: Comment Problem: I agree with Editor's comment. Proposed text: NONE ##Proposed disposition: Accepted ## The subject editor's note has been removed. ##Editing work: Done (WD6.0) Seq: 2 Clause: 3.12 Line: 1 Kind: Minor technical Problem: It is not clear across what environments "every" applies to. Is it, for example, all executions of a program, all instantiations of a specific programming language or what? Proposed text: NONE, since I am unable to deduce what the intended meaning is, but additional qualification wording is required from WG20. ##Proposed disposition: Clarification ## It is every run-time environment of program ## written by the program language ##Editing work: No action Seq: 3 Clause: 3.13 Line: 1 Kind: Minor Problem: Definition doesn't allow for a byte to be less than an octet Proposed text: Delete "that is equal to or larger than an octet," or replace with wording from ISO 10646 maybe? ##Proposed disposition: Accepted ##Editing work: Done (WD6.0) Seq: 4 Clause: 3.14 Line: Editors Note Kind: Minor Problem: Definitions for combining sequence and conjoining sequences are required. Proposed text: To be copied from ISO 10646 ##Proposed disposition: Accepted ##Editing work: Done (WD6.0) Seq: 5 Clause: 3.14 Line: Editors Note Kind: Minor Problem: Part of comment would be useful as a Note Proposed text: Add as a NOTE the last two sentences. ##Proposed disposition: Accepted ## Insted of the editor's note ## add the Notes in the character definition ## in ISO/IEC 10646 after the definition. ##Editing work: Done (WD6.0) Seq: 6 Clause: 3.16 Line: 1 Kind: Major Problem: Definition not used (probably). But definition of cultural convention set IS needed. Proposed text: Extract from 11017? ##Proposed disposition: Rejected ## Because guidline for collating sequence exist in ## this TR. ##Editing work: No action taken Seq: 7 Clause: 3.17 Line: 1 Kind: English/minor technical Problem: Proposed text: replace "is large enough" by "can" ##Proposed disposition; Accepted ## The definition has been totally rewritten. ##Editing work: Done (WD6.0) Seq: 8 Clause: 3.17 Line: 2 Kind: Minor Problem: No definition for maximal Proposed text: Delete "maximal" ##Proposed disposition: Accepted ## The definition is rewrited. ##Editing work: Done (WD6.0) Seq: 9 Clause: 3.18 Line: 1 Kind: Minor Problem: It is unclear what kind of character set is being referenced. Is it ANY character set used at execution? If so it should clearly state so. Proposed text: Replace "A" with "Any" ##Proposed disposition: Rejected ## It intends to mean that a certain character set ## that program will handle at execution time. ##Editing work: No action taken Seq: 10 Clause: 3.18 Line: 2 Kind: Minor Problem: Definition of "repetoire" required. Proposed text: Take from 10646? ##Proposed disposition: Rejected ## The word is not used in ISO/IEC 10646 specific ## meaning, but in dictionary sense. ##Editing work: No action taken Seq: 11 Clause: 3.18 Line: 2 Kind: English/technical Problem: Wider has implications in terms of handling of character sets, e.g wide characters in C/POSIX, which make in inappropriate to use here. Proposed text: replace "wider than" with "larger than that of" ##Proposed disposition: Accepted ##Editing work: Done (WD6.0) Seq: 12 Clause: 3.20 Line: 1 Kind: English/technical Problem: Unclear what "a set of multiple units" means Proposed text: Needs providing by WG20 ##Proposed disposition: Accepted ## The definition has been rewritten ##Editing work: Done (WD6.0) Seq: 13 Clause: 3.20 Line: 2 Kind: English/technical Problem: What does "continuous range" mean? Proposed text: Needs providing by WG20 ##Proposed disposition: Accepted ## The definition has been rewritten Seq: 14 Clause: 4.1.3.1 Line: NOTE 3 Kind: English/technical Problem: Wrong terms used. Proposed text: Replace "most programs" with "most programmers" ##Proposed disposition: Accepted ##Editing work: Done (WD6.0) Seq: 15 Clause: 4.1.3.1.2 Line: Last para Kind: English/technical Problem: Text repeats the meaning in the previous paragraph. Proposed text: Remove text ##Proposed disposition: Accepted ## The clause has been rewritten ##Editing work: Done (WD6.0) Seq: 16 Clause: 4.1.3.2 Line: 9 Kind: English/technical Problem: Unclear Proposed text: replace "BMP" with fully expanded meaning and "accordingly" with "respectively". ##Proposed disposition: Accepted ##Editing work: Done (WD6.0) Seq: 17 Clause: 4.1.3.2 Line: Just before Note 1 Kind: English/technical Problem: Proposed text: replace "as" with "within an" ##Proposed disposition: Accepted ##Editing work: Done (WD6.0) Seq: 18 Clause: 4.1.3.2 Line: Note 1 Kind: English/technical Problem: Wider has implications in terms of handling of character sets, e.g wide characters in C/POSIX, which make in inappropriate to use here, although this term is in the original text. Proposed text: Replace "wider" with "larger" twice. ##Proposed disposition: Rejected ## The word wider exist in the first edition of TR. ## The word does not imply POSIX/C sense. ##Editing work: No action Seq: 19 Clause: 4.1.3.2 Line: Note 2 Kind: Minor Problem: Note appears to be incorrect, since there is no assumption about data storage in these paragraphs, although it is in original text. Proposed text: remove Note ##Proposed disposition: Rejected ## Since the Note was the approved text of the ## first edition of this TR. ## Add [Editor's note] then make your ## opinion visible to reviewer. ##Editing work: Done (WD6.0) Seq: 20 Clause: 4.1.3.2 Line: Note 4 Kind: Minor technical Problem: This Note appears to be unrelated to the proposed handling of 10646 and, although in the original text, may now be obsolete Proposed text: removal or enhancement to be considered by WG20 or perhaps moving to some more appriate section. ##Proposed disposition: Rejected ## Since the text was in the approved text of ## the first edition of this TR. Although, the ## note is not directly related with ISO/IEC 10646, ## but still related with literal. It is unclear, ## if it has already be obsloete, or not. ##Editing work: No action taken Seq: 21 Clause: 4.1.3.3 + many others Line: 1 Kind: English/technical Problem: The term "programming language standard" is used. In the original text this is normally abbreviated to "standard" since it is unambiguous, although this is not done totally consistently, viz 4.1.3.5 (new) line 1. The term should be consistent throughout. Proposed text: Replace all occurences of "programming language standard" with "standard" throughout. ##Proposed disposition: Rejected/postpone ## If comments to change "programming language standard" ## to sort hand form "standard" comes from many people, ## then WG20 should add the abbreviation section to ## specify the term "standard", then replace all the ## "programming language standard" to "standard". ##Editing work: Right now, no action taken. Seq: 22 Clause: 4.1.3.3 Line: Paragraph 1 Kind: English/technical Problem: Text differs (slightly) from the general format in the original text. Proposed text: "The standard should define which characters are permitted in identifiers in a standard-conforming program. If the standard permits characters which are outside the minimal set defined in 4.1.3.1.1, especially if it implements ISO/IEC 10646-1, then consideration should be given to the inclusion of all characters listed in Annex A." ##Proposed disposition: Partially accepted ## The clause has been rewitten based on comments ## form project editor of the first edition. ##Editing work: Done (WD6.0) Seq: 23 Clause: 4.1.3.5.1 Line: 1 Kind: Minor Problem: Orginal text referring to octets may be obsolete. Proposed text: None - but consideration to the removal/editting of this text should be given by WG20. ##Proposed disposition: Rejected ## The rationale why the original text has become ## obsolete is unclear. ##Editing work: No action right now. Seq: 24 Clause: 4.1.3.5.2 Line: 1 Kind: Major Problem: It is unclear what is intended by this, since it is not phrased as a Guideline. SHOULD this be done? Is it to be deprecated? Is this trying to say something about the situation if the prgramming language provides such a data type? What are the implications? Proposed text: None - whole section to be reviewed for inclusion by WG20. ##Proposed disposition: Accepted ## The clause has been rewritten ##Editing work: Done (WD6.0) Seq: 25 Clause: 4.1.5.3 Line: 1 Kind: Minor Problem: Meaning unclear - Does this refer to the provision of a data type which can accommodate ANY possible execution environment, one that is provided by the processor or what? Proposed text: None - to be reviewed by WG20. ##Proposed disposition: Accepted ## The clause has been rewritten ##Editing work: Done (WD6.0) Seq: 26 Clause: 4.1.3.5.4 Line: 1 Kind: Minor Problem: Should basic character data types also be supported for assignment and comparison purposes? Proposed text: ##Proposed disposition: Clarification ## The basic character set is a special sub-set of ## extended of extended character set. In this sense, ## The basic character data type can be sub-type ## of extended character data type. ## the assignemnt and comparison also should be ## supported between basic character data type and ## other extended character data type. ##Editing work: No action Seq: 27 Clause: 4.1.3.5.5 Line: 3 Kind: Minor Problem: Should a recommendation be made that the presentation width is not the same as the number of characters. Proposed text: Replace in the second sentence "is the same" with "is one or the same" ##Proposed disposition: Accepted ##Editing work: Done (WD6.0) Seq: 28 Clause: 4.1.3.5.6 Line: 4 Kind: Technical Problem: Guideline makes something mandatory. Proposed text: In third sentence replace "must" with "should". ##Proposed disposition: Accepted ## The clause has been re-written. ##Editing work: Done Seq: 29 Clause: 4.1.3.5.7 Line: 2 Kind: English/technical Problem: "equivalent character semantics with the former character" is extremely unclear. It is presumably originated by case-conversion capabilities, however there appears to be no definition of character semantics anywhere. Proposed text: WG20 to provide ##Proposed disposition: Accepted ## Add another example for clarification ## Another example is to convert Latin alphabets to ## braille letter. ##Editing work: Done (WD6.0) Seq: 30 Clause: 4.1.3.5.7 Line: 1 Kind: English/technical Problem: "representation" is not the issue here, and perhaps the heading "transliteration" is also misleading. The required functionality is about characters (probably in fact about character codes) and not about appearance on a display/paper. Proposed text: Remove "representation" ##Proposed disposition: Accepted ##Editing work: Done (WD6.0) Seq: 31 Clause: 4.1.3.6 Line: 1 Kind: Technical Problem: ISO/IEC 646 is implied as the target. ShouldnĄt the recommendation be that 10646 be the target and 646 essentially deprecated? Proposed text: ##Proposed disposition: Accepted ## Merge two guidelines for ISO/IEC 646 and ISO/IEC ## 10646 into one guideline ##Editing work: Done (WD6.0) Seq: 32 Clause: 4.1.3.6.2 Line: 1 Kind: Major Problem: I don't think that either of the two proposed alternatives in the Editor's Note is the correct aproach. Proposed text: The new text should make recommendations in this area, with a pointer to the proposed project ordering. Whether the text is stable or not at this time is not relevant, since this could merely be a pointer to a future standard/recommendation. Consideration should be given to code point ordering as an alternative or switchable option anyway. ##Proposed disposition: Accepted ## Confirmed that the project editor of international ## ordering that the standard does not have any ## conformance requirement to the standard. ## Just bridge to invoke the international ordering ## engine is recommended to implementation of ## programming language standard. Therefore, only ## point is remained. ##Editing work: Done (WD6.0) Seq: 33 Clause: 4.1.3.6.2 Line: end Kind: Technical Problem: There are no recommendations about switching of collating seuqences, e.g. numeric orders. Proposed text: ##Proposed disposition: Rejected ## The switching may be done through cultural element ## switching mechansim, but may not appear on language ## syntax. So, no recommendation on switching is ## presented there. ##Editing work: Done (WD6.0) Seq: 34 Clause: 4.1.3.7.1 Line: 2 Kind: Technical Problem: The second sentences doesnĄt seem to be in line with the definition of extended character data type. Proposed text: Needs correction by WG20 ##Proposed disposition: Accepted ##Editing work: Done Seq: 35 Clause: 4.1.3.7.1 Line: Note 1 line 2 Kind: English/technical Problem: Grammar may cause interpretation problems. Proposed text: Second sentence to be "Each character in a combining or conjoining sequence of an extended character data type could be stored or processed separately." ##Proposed disposition: Accepted ##Editing work: Done (WD6.0) Seq: 36 Clause: 4.1.3.7.1 Line: Note 2 line 2 Kind: English/technical Problem: There need not be a corresponding pre-composed character. Proposed text: Insert before the comma ", if it exists" ##Proposed disposition: Accepted ##Editing work: Done (WD6.0) Seq: 37 Clause: 4.1.3.7.2 Line: All Kind: English/technical Problem: IĄm not sure what this whole guideline is for. In fact, do we want to make recommendations about multiple-byte code character sets apart from 10646? Proposed text: Delete guideline ##Proposed disposition: Rejected ## Some programming language e.g. COBOL support ## extended character set by multi-byte in addition ## to multi-octet. The multi-octet way is strongly ## recomended than multi-byte way, but guideline ## for multi-byte is still needed. ##Editing work: No action Seq: 38 Clause: 4.1.9.1 Line: - Kind: English/technical Problem: Character sets examples not included Proposed text: Add bullet "the use of character sets and collation" sequencesĀ ##Proposed disposition: Rejected (Clarification & Rationale required) ## Ask to originator of this comment to clarify ## the rationale for having the character set ## related processor option. ##Editing work: No action right now. Seq: 39 Clause: 4.5.4.1 Line: Editors note Kind: English/technical Problem: Suggested items donĄt seem very relevant in the same sense as the other ones to revision compatibility. Proposed text: None to be included. ##Proposed disposition: Postpone (Need to here other opinion) ## This comment will be resolved after ## receiving ballot comment of PDTR ballot. ##Editing work: No action right now. Seq: 40 Clause: 4.7.1 Line: 1 Kind: Technical Problem: No definition for "cultural convention set". It's also not clear whether this definition should also include a character set as part of the set of elements and if so what the implications are. Finally, does there need to be anything recommended about the selection of a set prior to process/thread initiation? Proposed text: Add definition for "cultural convention set" to 3.x. ##Proposed disposition: Accepted ## Added the definition of cultural convention set. ##Editing work: Done (WD6.0) Seq: 41 Clause: 4.7.1 Line: 1 Kind: Technical Problem: Does there need to be anything recommended about the selection of a set prior to process/thread initiation? Proposed text: ##Proposed disposition: Clarification ## If programming language standard support thread, ## selection of cultural convention must be done ## thread by thread, not process wide. Otherwides, ## switching of cultural convention set may have ## side effect then change the behavior of cultural ## convention set dependent function executing on ## other thread. ##Editing work: Done (WD6.0) Seq: 42 Clause: C.2.1 Line: 5 Kind: English Problem: "Shall" used incorrectly. Proposed text: Replace "shall" with "should" ##Proposed disposition: Accepted ##Editing work: Done (WD6.0) Seq: 43 Clause: C.2.1 Line: end Kind: Technical Problem: It's unclear what standards writers/compilers etc need to do Proposed text: Add "Note: Since the expected execution character set might not be known when the source code is processed it may be necessary for the source code character set to be known at program load/initiation/execution time." ##Proposed disposition: Accepted ##Editing work: Done (WD6.0) Seq: 44 Clause: C.2.2 Line: All Kind: Technical Problem: Above Note (comment 43) removes need for this specific paragraph, since it is more general. Proposed text: Remove sub-section C.2.2 ##Proposed disposition: Accepted ##Editing work: No action right now Seq: 45 Clause: C.2.3 Line: All Kind: Technical Problem: This appears to be extremely language specific and makes a recommendation which only appears to cover automatic type-conversion languages. Proposed text: Remove sub-section and/or make the recommendation a guideline in the main body of the TR. ##Proposed disposition: Rejected ## The text says that the guideline is only ## apprecable to the language that has ## automatic type-conversion. Not for all ## language standard. ## Even if the guideline is conditional one, ## it is not needed to remove such conditional ## guideline from this TR. ##Editiong work: No action. Seq: 46 Clause: Many Line: Kind: English Problem: There are a significant number of spelling errors and infelicities in the use of the English language. Proposed text: Proposed corrections of text will be faxed directly to the editor. ##Proposed disposition: Accepted ##Editing work: Done (WD6.0)