Subject: SC22 N2520 - JTC 1 Voting Summary on DTR 10176 - Guidelines for Programming Language Standards Preparation

From: "william c. rinehuls" <[email-masked]>
Date: Wed, 16 Jul 1997 16:10:41 -0400 (EDT)

__________________ beginning of title page __________________________
ISO/IEC JTC 1/SC22
Programming languages, their environments and system software interfaces
Secretariat:  U.S.A.  (ANSI)

ISO/IEC JTC 1/SC22
N2520

July 1997

TITLE:
JTC 1 Summary of Voting on Approval of DTR 10176 - Guidelines for the
Preparation of Programming Language Standards

SOURCE:
Secretariat, ISO/IEC JTC 1/SC22

WORK ITEM:
JTC 1.22.13

STATUS:
N/A

CROSS REFERENCE:
SC22 N2163, N2491

DOCUMENT TYPE:
Summary of Voting

ACTION:
To SC22 Member Bodies for information.

To WG20 for preparation of a Disposition of Comments Report and
preparation of the final text for publication.

Address reply to:
ISO/IEC JTC 1/SC22 Secretariat
William C. Rinehuls
8457 Rushing Creek Court
Springfield, VA USA 22153
Telephone:  +1 (703) 912-9680
Fax:  +1 (703) 912-2973
email:  [email-masked]

________________end of title page; beginning of summary __________________

ISO/IEC JTC 1                                                         
Information Technology                                                

ISO/IEC  JTC 1 N 4782                   

DATE:  1997.06.25     

REPLACES                                     

DOC TYPE:
Summary of Voting/Table of Replies                                        

TITLE:
Summary of Voting on Document JTC 1 N 4579, DTR 10176, Guidelines for 
the Preparation of Programming Language Standards                     

SOURCE:
JTC 1 Secretariat                                                     

PROJECT:                   

STATUS:
Although the majority of P-members voted to approve this document, three  
P-members have submitted comments with their positive votes and three  
P-members have submitted negative votes.  SC 22 is instructed to respond
to these comments before submitting the TR for publication.                                        

ACTION ID:  ACT 

DUE DATE:            

DISTRIBUTION:  P and L Members                                             

MEDIUM:  D

DISKETTE NO.:  138       

NO. OF PAGES:  13        

Secretariat, ISO/IEC JTC 1, American National Standards Institute, 11 
West 42nd Street, New York, NY  10036; Telephone:  1 212 642 4932;    
Facsimile:  1 212 398 0023; Email:  [email-masked]                 

VOTING SUMMARY OF JTC 1 N 4579

"P" Members         Approve  Approve With  Disapprove  Abstain  Comments
                             Comments

Australia *         X
Austria *           X
Belgium *
Brazil  *           X
Canada  *           X
China  *
Columbia							
Denmark *                    X
Egypt  *            X
Finland *           X
France *            X
Germany *                                               X
Hungary
Ireland *           X
Italy
Japan *                      X                                See Comments
Korea, Republic of  X
Netherlands *                                X                See Comments
New Zealand
Norway *            X
Romania  *          X
Russian Federation* X
Slovenia *
Sweden *                     X                                See Comments
Switzerland *       X
United Kingdom *                              X               See Comments
USA  *                                        X               See Comments

* ISO/IEC "P" member of SC22

 Attachment 1   Denmark

Due to the change in ISO/IEC 10646 of the encoding of Hangul characters,  
we propose to change the allowable characters defined in the appendix on
extended identifiers as follows.

Remove the range:  U3400..U4DFF
Insert the range:  UAC00..UD7AF

Attachment 2   Japan

Japan's Comments on ISO/IEC DTR 10176,Title: Information technology --  
Guidelines for the preparation of Programming language standards

The National Body of Japan approves ISO/IEC DTR 10176 with the following  
comments. 

1. Category (Editorial)  at the note 2 of 3.6.5
   Proposed modification: replace "in not a" with "is not a".

2. Category (Editorial)  in the subclause 3.6
   Problem: the third level clause number 3.6.7 and 3.6.8 are duplicated.
   Proposed modification: renumber after the first occurrence of 3.6.8.

3. Category (Editorial)  at the note 1 and 2 of 3..11
   Proposed modification: replace "of character" with "of a character".

4. Category (Editorial)  at the note 4 of 4.1.1
   Problem: unnecessary line break exists.
   Proposed modification: reformat.

5. Category (Editorial)  at the 4.1.3
    Proposed modification: move ", e.g. ISO/IEC 10646-1" at immediate  
    after of "multi-octet character set",
    and add ", e.g. ISO/IEC 8859-1" at the end of the sentence.

6. Category (Editorial)  at the note 1 of 4.1.3.1.3
   Proposed modification: replace "is by not English" with "is not English".

7. Category (Editorial)  at the note 1 of 4.1.3.1.4
   Proposed modification: remove the last sentence.
   Reason: The annex A does not discuss about possible solution.

8. Category (Editorial)  at the first paragraph and note 1 of 4.1.3.3
   Proposed modification: replace "every repertoire" with "entire  
   repertoire".

9.  Category (Editorial)  at the note 1 of 4.1.3.3 
    Proposed modification: Replace "In the case if repertoire list which  
    enumerate allowable repertoire of characters for the character
    datatype is not specified explicitly," with "In the case if the
    value space of a character datatype is not specified explicitly, by
    using the repertoire list that enumerate allowable repertoire of
    characters for the datatype,"

10. Category (Editorial)  at the last sentence of 4.1.3.3.3
    Proposed modification: makes the last sentence as note and reword it  
    as "Assignment from a character datatype whose value space is ISO/IEC
    646 IRV to another character datatype whose value space is
    ISO/IEC 10646-1 is an example of inter character datatype assignment." .

11. Category (Editorial)  at the second sentence of 4.1.3.4.2
    Proposed modification: replace "couture" with "culture".

12. Category (Editorial)  at the note 5 of 4.1.3.5
    Proposed modification: replace "being standardized as CD 14651" with  
    "being standardized towards ISO/IEC 14651".

13. Category (Editorial)  at note of 4.7.2
  Proposed modification: replace "TR 11017" with "ISO/IEC TR 11017".

14. Category (Technical)  in Annex A
    Proposed modification: Add notes and clarify:
       (1) The character repertoire listed in this annex is based on the  
           ISO/IEC 10646-1:1993, and subject to be changed if ISO/IEC
           10646 is amended.
       (2) The character repertoire listed in this annex is a recommended  
           repertoire for use of user defined identifier, and each
           programming language standard or implementation of the
           standard can modify the repertoire, considering the 
           characteristics of the language and requirements, at the
           standardization or implementation of the language.

15. Category (Technical)  in Annex A
    Proposed modification: Remove the following characters form the list:  
    309b-309e, 30fd, 30fe, 3094, 30f7-30fa, and characters in the  
    compatibility zone (f900-ffdc).

Attachment 3   Netherlands

COMMENTS TO THE NEGATIVE VOTE

Removal of Annex A is required to turn our NO vote into YES. This Annex
contains rules for characters from scripts to be permitted in
identifiers, without any indication that these are the right choice.
Only the NBs of countries where these scripts are in use can state that,
and these were not consulted. In particular, the rules for Indian
scripts allow only for consonants, not vowels, in identifiers, which
will cause great merriment in India, to the expense of the reputation of
SC22/WG20 as a body of experts, and of SC22 as a serious standards
developing group.

A number of our comments in N 2163 appear to be proposed for rejection
in N 2411 without any justification. Our vote will remain NO as long
as no clarification is given.

Editorial comments

It is a pity that in a DTR still sentences occur not checked for correct
English. Omission of the Definite or Indefinite Article is not allowed
in the English language, a well known stumble-block to Japanese writers.
Some are even not understandable. We mark these with This Sentence Is
Incomprehensible (TSII).

3.6.3 Change:
Each element of a combining sequence -->
Each element of a composite sequence
Add after last sentence:
(as it is in ISO/IEC 10646-1.)

3.6.5 Change:
(Note 2)
A composite sequence in not -->
A composite sequence is not -->

3.6.12 Note 2:
Insert "the" and "a".

3.6.16 Note 2 Change:
the same with -->
the same as

4.1.3.1.2 Note 4 Change:
for coding -->
for character coding
(SC29 is developing standards for audio-visual coding, not meant here.)

4.1.3.1.3 Note 3:
The SC2 intends ....
Remove this sentence. A TR is about facts, not intentions.

4.1.3.1.4 Note 3:
Remove this note. A TR is about facts, not intentions.

4.1.3.2 Note 1 Change:
variant -->
version

4.1.3.3.1 Notes 1, 2 " "
STII (see above)

4.1.3.4.2 Notes 1, 2, 3
STII (see above)
"couture" ???

4.1.3.6 Change:
whose values space -->
whose value space
(NOTE):
should not to require -->
should not require -->

4.1.3.1.4, 4.7.2 Change:
Programming language committee should consider -->
The Programming language committee should consider -->

Attachment 4   Sweden

Editorial comment: The document has been typeset for US Letter format,  
which is evident from the uneven margins on even/odd pages when printed in
A4 paper. Overall, the margins are too narrow for easy use, at least when
printed on A4.

Attachment 5   UK

UK vote on JTC1 N4579 - DTR 10176: Document SC22/WG20 N477

The UK votes NO. The vote will become YES if  Issues 1-3 and 12 are  
resolved satisfactorily.

A number of issues which were identified as major technical issues in the  
PDTR ballot were not resolved satisfactorily, or at all, in the
Disposition of Comments SC22 N2163:

Issue 1: 
Clause 4.7 provided unclear and minimal guidance for the handling of  
non-character set related issues for internationalization. A
recommendation for WG20 was made.
Disposition:
None provided, but a reference to TR 11017 Framework for  
internationalization exists.
Action:
4.7.2 is especially unclear as to the meaning and needs to be clarified  
for subsequent processing.

Issue 2:
Clause 4.1.3.1.1  provided no guidelines for ISO 10646 handling.
Disposition:
Refers to CHARACTER datatype.
Action:
Datatypes are not relevant to character sets used for program text. Hence  
the original problem is still unresolved.

Issue 3:
Clause 4.1.3.4.2  makes no recommendations about classes of characters  
which should be provided for internationalized applications.
Disposition:
None
Action:
Recommendations need to be included.

In addition a number of other issues need to be addressed:

Issue 4:
Clause 3.6.8 refers to a  family  when it is not clear that a family is  
being referred to. (Note the use of data type as two words or datatype as
one word is inconsistent throughout.)
Action:
Change definition to  A character datatype is a datatype whose value space  
is a character set.  Also replace  wide  with  large  in the Note.

Issue 5:
Clause 3.6.9 muddles codes and values.
Action:
Replace definition with  An octet datatype is the datatype whose values  
are single octets (often used for character sets and private encoding.)
Also replace  wide  with  large  twice in the Note.

Issue 6:
Clause 3.6.10 is confused.
Action:
Replace definition with  An octet string datatype is a dataype of  
variable-length whose elements are of an octet datatype.  Also replace  of
extended character sets  with  an extended character set .

Issue 7:
Clause 3.6.12 could refer to non-integer multiples of octets
Action:
Replace  that size is equal to or larger than two octets  with  whose  
values are multiple octets

Issue 8:
Clause 4.1.3.1.3 Note 2 last sentence refers to an Annex A which no  
longer exists.
Action:
Delete

Issue 9:
Clause 4.1.3.1.3 Note 3 last sentence refers to an SC2 intention.
Action:
Either delete or fully explain.

Issue 10:
In the DTR Clause 4.1.3.2 was identified as limiting to sequence of octets.
Disposition:
WG20 intended to review, but no changes have been made, so the problem is  
still outstanding.
Action:
WG20 should review before further progress.

Issue 11:
Clause 4.1.3.3.2 Notes 2 does not make any sense to this (English) reader.  
Is it trying to say that portability can be maintained if octet datatypes
are used? This may be true for a limited subset of portability issues. If
so then it should say which classes of portability would be maintained.
Action:
Needs to be re-written

Issue 12:
Clause 4.1.3.6 Note was recommended to be replaced with a guidelines. This  
was accepted by WG20, but no change has been made to the document.
Action:
Change needs to be made in response to original problem statement before f 
urther progression of the document.

Issue 13:
Clause 4.1.3.7 a and b) mentions octet-string when header refers to  
multi-byte
Action:
In a) delete  stored in an octet string datatype 
In b) delete  in an octet string datatype 

Issue 14:
Many English problems
Action:
Issue :
Clause 3.6.11
In Note 2 replace  character bound  with the character boundary 
4.1.3.1.5 
second sentence insert  a  after  permit 
4.1.3.3.1
Replace  the character  with  a character  and  is  by  includes 
In Note 1 replace  if  by  that a  and  emamerate  by  enumerate 
4.1.3.3.2
Replace  use  by  provide 
In Note 1 replace  wide  by  large  and  all repertoire  by  all  
repetoires 
In Note 3 delete  to 
4.1.3.4.2
In second sentence replace  couture  by  culture 
In Note 2 replace  will be used by  by  should be usable by a  
4.1.3.5
In the second paragraph replace  one of   by  a 
4.1.3.6
Replace  the character  by  a character 
In the Note replace  should not to  by  need not ,  should be stored in   
by  could be stored in a  
In the final paragraph insert  single value of a  before  datatype ,  the   
before  provision , and replace  distinct datatype from character datatype
by  datatype distinct from other character datatypes 
4.1.3.7
Replace  in  by  using 
In b) replace  bound  by  boundary 

Attachment 6   USA

The US National Body votes to Disapprove with comments ISO/IEC 
DTR 10176 - Guidelines for the Preparation of Programming Language  
Standards. 
See Comments listed below.

Comments:

 General comments
 --------------------------
 
 In general, we are finding TR 10176 rather uninformed about
 object-oriented language design and mostly irrelevant to the major new
 language development that it might be attempting to address, namely
 Java. We also finding that the document is anchored in the past in its
 usage of terminology and its application of coded character sets.
 These points are developed in the technical comments section.
 
 Furthermore, the document requires a lot of editorial work, there are
 many typos and many parts of the document are difficult to understand
 text sections. These issues are explained in the following editorial
 comments.
 
 Overall, the U.S. position is that the document should be withdrawn,
 unless it is completely rewritten to take into account the current
 language technology and submitted to a comprehensive editorial phase.
 
 Technical comments
 --------------------------
 a) Byte terminology
 Ref: 3.6.1, 3.6.11 and 3.6.12 
 
 The usage of the byte terminology should be completely avoided.
 This document is redefining the byte in 3.6.2 in a manner slightly
 different from well known standards (for example ISO/IEC 2022:1994
 defines it as 'a bit string that is operated upon as a unit'). Despite
 the fact that these definitions refer to the byte as an entity with a
 variable bit size, it is a well-established practice that the byte is
 assimilated to an octet. To avoid the issue, increasingly standards
 are referring only to the octet that has a very precise association
 with 8-bit encoding. Using the concept of multi-byte and two-octet bytes 
 in the same sentence is more confusing than clarifying.
 
 b) Guideline: Character sets used for program text
 Ref 4.1.3.1.1
 
 New languages should not be restricted to the usage of invariant part
 of ISO/IEC 646. This limitation is not realistic anymore and is de
 facto ignored by new languages. This would exclude characters like
 '[]{}|' that are commonly used in today languages. A vast majority of
 programmers is using environments based on (or related to) ISO/IEC
 8859 or even ISO/IEC 10646, not national variants of ISO/IEC 646. This
 guideline is anchored in the past, not the present situation.
 
 c) Guideline: Guideline: Character datatype
 Ref 4.1.3.3.1
 
 "The character datatype should be independent from any coded character
 set."
 
 The most recent developments in language technology like Java are
 being done, with good reasons, in contradiction with this guideline.
 The correct way to implement 10646 in a computer language is to
 *identify* the character datatype with a fixed-width encoding form of
 the universal character set. The point of a universal character set
 for a programming language is to *use* the universal character set
 directly, not simply to treat it as a reference by which to define all
 the single-byte, multi-byte anarchy that is currently implemented.
 d) Guideline: Character transliteration
 ref 4.1.3.4.2 
 
 This section distorts the standard meaning of "transliteration". What
 is meant here are classes of character transformation, explicitly
 case-transformation, and width-transformation (for Japanese
 hankaku/zenkaku characters). In addition, we presume that 'couture'
 was supposed to be 'culture'.
 
 e) Guideline: Cultural convention set switching mechanism
 ref 4.7.1 
 
 This guideline for provision of a mechanism such as setlocale() on a
 per-thread basis is too limited and inappropriate for object oriented
 languages like Java. Java provides I18N functionality through a set of
 classes which reflect an entirely different architecture.
 
 In general the guidelines in TR 10176 reflect a view of programming
 languages which generally seems to be completely uninformed by
 object-oriented programming language design. This is just one example.
 
 f) Recommended extended repertoire for user-defined identifier
 Ref Annex A
 
 The annex needs a complete reworking.
 This annex has errors scattered throughout. (e.g. U+0384 where U+0386
 is clearly intended, in the Greek set) It is not up-to-date against
 Unicode 2.0 (or 10646 plus Amendments). For example, it arbitrarily
 omits the Hangul syllables (U+AC00 to U+D7AF3), and the CJK Unified
 Ideographs is a mixed bag containing characters that have nothing to
 do with Ideographs (Arabic presentation forms, Halfwidth and Fullwidth
 forms of Latin, Kana and Hangul,.). It also arbitrarily legislates
 against modifier letters or IPA values for identifiers.
 
 However, the worst error is in claiming that combining marks do not
 belong in identifiers. The fallacy of this can be seen by looking at
 the Devanagari list, which is utterly nonsensical. The recommended
 values for identifiers are U+0905-U+0939, U+0958-U+0962. In other
 words, this annex is recommending that *only consonants or initial
 vowels* are o.k. in Devanagari identifiers, but other vowels and
 virama should be omitted.
 
 See the Unicode Standard, pp. 5-25 to 5-27, plus corrections posted on
 the Unicode website, for a meaningful recommendation regarding how to
 extend identifier syntax to the 10646 repertoire. (The Java
 implementation of identifiers in Unicode is very close to this
 recommendation.)
 
 Editorial comments
 --------------------------
 
 a) Guidelines on the use of character sets
 Ref 4.1.3
 
 The following text "including multi-octet character sets and
 non-English single octet character sets, e.g. ISO/IEC 10646-1." is
 well intentioned, but badly worded, since it implies that 10646-1 is a
 single octet character set! This could be improved by swapping the two
 elements of the sentence.
 
 b) Guideline: Character sets used in character literals
 Ref 4.1.3.1.4
 
 "Any conforming processor should be required to accept method c) to
 reepresent a character literal outside of "minimal set" defined in
 4.1.3.1.1, any "non-printing character", or any special-purpose
 character, in a way that is independent from code value of the
 character of the character in any coded character set."
 
 We do not understand the meaning of the paragraph. The representation
 of a literal by its 10646 value cannot be independent of its code
 value *in* 10646, which is itself a coded character set.
 
 c) Guideline: Character sets used in comments
 Ref 4.1.3.1.5 (Note)
 
 Change
 "... Since comments are intended for human reading and hence escape
 mechanisms are unnecessary, there is no disadvantage in printing
 characters simply representing themselves (apart of course from any
 characters or sequences of characters marking the end of the comment),
 and in limiting non-printing characters to those (like carriage return
 and line feed) necessary for layout purposes."
 
 By
 "Program comments are intended for human reading. Except for the
 provision of unambiguous characters or sequences of characters to
 delimit the comments, the specification of a computer language should
 not restrict characters which can occur in comments. No escape
 mechanism should be necessary for inclusion of any character in
 comments."
 
 d) Guideline: Character datatype
 
 "The programming language standard should provide the character
 datatype whose value space is every repertoire of the extended
 character set in an execution environment."
 
 We don't understand that sentence. We presume this intends to say "the  
 entire repertoire". Furthermore, the intent of the term "extended
 character set in an execution environment" is unclear.
 
 Note 1: "In the case if repertoire list which emamerate allowable
 repertoire of characters for the character datatype..."
 
 That note is completely incomprehensible. Besides the obvious typos
 (emamerate instead of enumerate, lack of articles, etc.), we cannot
 make any sense of the note. This defeats the purpose of this document
 that is aiming at being a set of 'guidelines'.

 e) Guideline: Octet and octet string datatype
 ref 4.1.3.3.2 
 
 Note 1 "The value space of the octet datatype is wide enough to
 represent every repertoire of the basic character set, but not all
 repertoire in the extended character set."
 
 Again, we don't understand this, we presume the author meant "the
 entire" for "every" and "all" here. The sentence needs to be
 completely rewritten (no suggestion as we don't understand it).

__________________end of SC22 N2520 ___________________________________