Subject: Document SC22 N2163

From: "william c. rinehuls" <[email-masked]>
Date: Fri, 7 Jun 1996 18:37:59 -0400 (EDT)

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:  [email-masked]

____________________________________________________________________________

                          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--------------------