Subject: SC22 N2491 - Revised Disposition of Comments Report on PDTR 10176

From: "william c. rinehuls" <[email-masked]>
Date: Mon, 16 Jun 1997 16:12:39 -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
N2491

June 1997

TITLE:
Revised Disposition of Comments Report on Concurrent PDTR Registration and
PDTR Ballot for PDTR 10176 - Information technology - Guidelines for the
Preparation of Programming Language Standards (Revision of TR 10176:1991)

SOURCE:
Secretariat, ISO/IEC JTC 1/SC22

WORK ITEM:
JTC 1.22.13

STATUS:
This document replaces SC22 N2411

CROSS REFERENCE:

SC22 N2163, N2411

DOCUMENT TYPE:
Disposition of Comments Report

ACTION:
To SC22 Member Bodies for information.

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

___________________end of title page; beginning of text _________

Disposition of Comments Report
CD ballot comments to PDTR 10176

COMMENTS ACCOMPANYING UNITED KINGDOM NEGATIVE VOTE

UK COMMENTS ON ISO/IEC JTC 1/SC 22 N 2029 : GUIDELINES FOR
PREPARATION OF PROGRAMMING LANGUAGE STANDARDS
(ISO/IEC TR 10176 REVISED)

The UK votes APPROVAL of the registration of this draft as a PDTR but
DISAPPROVAL of the PDTR ballot for the technical reasons listed below:-

Seq no:	 1
Clause:	4.7
Kind:	Major technical
Problem:	The guidelines for handling non-character set related 
issues within internationalization are minimal and unclear. These should
be added before further progression of this report takes place.
Proposed text:
For WG20 - at the very least a minimal set should be specified and 
consideration should be given to selection mechanisms, especially that
at the moment of process/thread initiation. Note a definition of "thread"
and "process" will be needed

Approved Disposition: The current draft of TR 10176 recommends that
the internationalization functionality supported by each programming
language standard should be cultural elements sensitive, and the
cultural elements specification that are referred to by the 
internationalization functionality should be switch-able at run-time,
instead of compile time. As pointed out, the current draft has no
guidelines which suggests what kinds of internationalization
functionality should be supported by each programming language
standards. Instead, WG20 is now proposing an NP for an
internationalization API. When the standard is established, the API will
be able to called from every programming languages. Since the approved
standard is now on quite early stage, the standard can not be refereed to
by this TR. The standard will be refereed to by future revision of this
TR.

Seq no:	 2
Clause:		4.1.3.1.1
Kind:	Major technical
Problem:	No guidelines provided related to 10646 handling. Some 
text is in Note 3, but this is not a guideline in any way.
Proposed text:

Approved disposition: WG20 believe that provision of a CHARACTER data
type that can contains the repertoire of ISO/IEC 10646 is sufficient
for 10646 handling from the view point of programming language
standards.
Also, the PDTR recommends the use of a larger repertoire in ISO/IEC
10646 in user defined identifiers and CHARACTER literal.

Seq no:	 3
Clause:	3.6.16
Line:	1
Kind:	Major technical
Problem:	Definition  will be extremely unclear to readers who have 
not read 11017.
Proposed text: 
Examples, as notes, should at least be provided here.

Approved disposition: Accepted.  Add note and list examples of cultural
convention
in it.

Seq no:	 4
Clause:	3.6.17
Line:	1
Kind:	Major technical
Problem:	This is not a definition. Usage of "ideally located" is 
not acceptable, also term "application platform" needs to be defined.
Proposed text:

Approved disposition: This definition is the same wording as in the
approved TR 11017. 

Seq no:	 5
Clause:	4.1.3
Line:	First two paragraphs
Kind:	Major technical
Problem:	These two paragraphs do not appear to relate to later
guidelines.
Proposed text:
These need to be restructured as an overall heading for the sub-clause
and some of the text moved into additional notes, e.g. justification.

Approved disposition: Accepted.

Seq no:	 6
Clause:	4.1.3.4.2
Kind:	Major technical
Problem:	Guidelines is inadequate in not making recommendations 
about classes of characters which should be provided for writing 
internationalised applications.
Proposed text:
To be reviewed by WG20, but should include firm recommendations related
to upper/lower case, alphabetic, alphanumeric. Other categories may not be 
needed for internationalised applications and therefore  should be added

in a Note.

Approved disposition: The character classifications exist in the WD of
the cultural elements specification method standard (IS 14652). And WG20
believes that those classification should be supported by every
programming language standard. 

Seq no:	 7
Clause:	4.1.3.4.3
Kind:	Major technical
Problem:	Clause appears to have no meaning, since "equivalent 
character semantics" is not defined.
Proposed text:
Firm guideline/recommendation from WG20 is required

Approved disposition: Accepted. Describe the functionality by
not using "equivalent character semantics". The clause would be
as follows:

"The programming language standard should provide
a means to map a character to another, for example
map an upper case letter to the corresponding lower case
letter. The programming language standard should require that the means
supplied do not depend on a specific coded character set, a specific
culture, nor a specific natural language."

Seq no:	 8
Clause:	4.1.3.5
Kind:	Major technical
Problem:	ISO 10646 does not have enough prominence.
Proposed text:
Move Note 5 before Note 1, also a guideline for the collating ordering
if the standard supports 10646 should be provided, e.g. by ordering of 
character  codes if nothing else.

Approved disposition: Rejected. The subject standard is now being
developed.
Further revision of this TR may be able to emphasize the ordering of
10646 data, when IS 14651 is approved

Seq no:	 9
Clause:	4.1.3.5
Kind:	Major technical
Problem:	No guidelines provided regarding  switching of collating 
sequence dynamically. [Perhaps this should be applied in general to the 
switching of a character set as well?]
Proposed text:
For WG20 to provide.

Approved disposition: Accepted.  See 4.7.1

Seq no:	 10
Clause:	Annex C
Kind:	Major technical
Problem:	This appears to consist of many guidelines, in addition to 
some exposition, and should therefore be incorporated into the main body

of the report. In addition many paragraphs duplicate wording elsewhere.
Proposed wording:
In addition to moving paragraphs a certain amount of rework may be 
necessary in the paragraphs new positions:
Move C.1 para 1 + a) + e) to  4.1.3.3.2
Delete b) - duplicate in 4.1.3.6
Delete c) and d) - duplicates in 4.1.3.7
Move C.2.1 to 4.1.3.1.4
Move last sentence of C2.2. to 4.1.3.3.3 - rest is duplicate
C.3 needs to be complete (probably) and moved elsewhere
Delete C.4 unless some useful wording can be provided.

Approved disposition: Accepted.  Annex C will be removed. The contents
of paragraph 1 will be moved to 4.1.3.3.1 and 4.1.3.3.2.

Seq no:	 11
Clause:	2
Line:	last
Kind:	Minor
Problem:	Reference to BS 6154 out of date
Proposed text:
Change reference to DIS ???

Approved disposition: Accepted. (DIS 14977)

Seq no:	 12
Clause:	3.6.7
Line:	1
Kind:	Minor technical
Problem:	Term "Execution environment" not defined
Proposed text: 
Add definition

Approved disposition: Accepted.

Seq no:	 13
Clause:	3.6.11
Line:	2-5
Kind:	Minor technical
Problem:	Not part of a definition
Proposed text:
These sentences should form a Note or multiple notes.

Approved disposition: Accepted.  Add a note and move everything from the
2nd line on to the note.

Seq no:	 14
Clause:	3.6.11
Line:	4
Kind:	English
Proposed text:
Replace "consists" with "consisting" and "type" with "type units"

Approved disposition: Accepted.

Seq no:	 15
Clause:	3.6.11
Line:	5
Kind:	English
Proposed text:
replace "character boundary need to be detached" with "the character 
boundary needs to be distinguished from the byte boundary"

Approved disposition: Accepted.

Seq no:	 16
Clause:	3.6.11
Line:	6
Kind:	English
Proposed text:
Replace "then become" with "thus becoming" and "Here after, T" with "In 
following references the"

Approved disposition: Accepted.

Seq no:	 17
Clause:	3.6.12
Line:	Last
Kind:	English
Proposed text: 
Replace "Here after," with "In following references the"

Approved disposition: Accepted.

Seq no:	 18
Clause:	3.6.12
Line:	Middle
Kind:	Minor technical
Problem:	Not part of a definition
Proposed text:
Middle sentences should be a Note.

Approved disposition: Accepted.

Seq no:	 19
Clause:	3.6.12
Line:	Editors Note
Kind:	?
Problem:	It's not clear what the purpose of this note is.

Approved disposition: Remove Editor's note. No editor's note will 
remaine in the final text of this TR.

Seq no:	 20
Clause:	3.6.13
Line:	1
Kind:	English
Proposed text:
Replace "The...VGA" with "A presentation device with a fixed width and 
height character font. A VGA"

Approved disposition: Accepted.

Seq no:	 21
Clause:	3.6.14
Line:	1
Kind:	English
Proposed text:
Delete "that is" and replace "alphabet." with "alphabet, a"

Approved disposition: Accepted.

Seq no:	 22
Clause:	4.1.3.1
Line:	1
Kind:	English
Problem:	Guidelines isn't about specifications
Proposed text:
Replace "specifications" with "text"

Approved disposition: Accepted.

Seq no:	23
Clause:	4.1.3.1.1
Line:	Note 2
Kind:	Minor technical
Problem:	Last line is not correct.
Proposed text:
Delete last sentence.

Approved disposition: Accepted.

Seq no:	 24
Clause:	4.1.3.1.1
Line:	Note 3
Kind:	Minor technical
Problem:	Refers to bits
Proposed text:
Replace "sixteen or thirty one bit" with "multi-octet"

Approved disposition: Accepted.

Seq no:	 25
Clause:	4.1.3.1.2
Line:	1
Kind:	English
Problem:	
Proposed text:
Replace "character" with "characters" in title

Approved disposition: Accepted.

Seq no:	 26
Clause:	4.1.3.1.2
Line:	Note line 3
Kind:	English
Problem:	
Proposed text:
Replace "has very similar to above" by "is very similar to these", "that
the" to "that," "some of" by "some", "those" by "these", "works" by 
"acts", "delimiter" by "delimiters", "that have the identical or" by
"the identical or a"

Approved disposition: Accepted.

Seq no:	 27
Clause:	4.1.3.1.3
Line:	Notes
Kind:	Recommendation
Problem:	These might be suitable as a basis for common notes at the 
head of this sub-clause.

Approved disposition: Accepted in principle.

Seq no:	 28
Clause:	4.1.3.1.3
Line:	Note 2
Kind:	Minor technical
Problem:	Term "application" not defined
Proposed text:
Replace "application" by "the program"

Approved disposition: Accepted.

Seq no:	 29
Clause:	4.1.3.1.4
Line:	Para 3
Kind:	Minor technical
Problem:	Does 10646 have the concept of an "escape character"?
Proposed text:
Remove "as an escape character or"

Approved disposition: (Clarification) 1. ISO 10646 has the concept
of ESC characters and escape sequences. Beside, the "Escape character"
used in the text is a character that has a special meaning in a 
programming language, such as backslash character in C language.

Seq no:	 30
Clause:	4.1.3.1.4
Line:	Editors note
Kind:	Minor technical
Problem:	Is the concept of a type for a literal well understood, 
especially for "extended character data type"? [Some languages will not 
have a need for the concept.]
Proposed text:
Additional Notes of explanation would probably be welcome.

Approved disposition: The Editor's note will be removed from the
final text of the TR.

Seq no:	 31
Clause:	4.1.3.1.4
Line:	Note 1 second para
Kind:	Minor technical
Problem:	This para is incorrect, since these needs do not relate to 
"suitability of the language for general processing of character data."
Proposed text:
Remove para

Approved disposition: Rejected. This text has not been changed from
previous approved version.

Seq no:	 32
Clause:	4.1.3.1.4
Line:	Note 2
Kind:	Minor technical
Problem:	Note incorrect
Proposed text:
Remove note

Approved disposition: Accepted. Note 2 removed.

Seq no:	 33
Clause:	4.1.3.2
Line:	2
Kind:	Minor technical
Problem:	Refers to character data as a "sequence of octets". This 
may place a limitation  on the language design, which does not need any 
concept of character length
Proposed text:
WG20 to review

Approved disposition: A "Character" can be stored within CHARACTER or
OCTET data type. To manipulate characters stored in the OCTET data
type correctly, the programming language need to detect character
boundary in OCTET string. The clause is prepared for C language.

Seq no:	 34
Clause:	4.1.3.2
Line:	Para 2
Kind:	English
Problem:	
Proposed text:
Replace "what" by "in what"

Approved disposition: Accepted.

Seq no:	 35
Clause:	4.1.3.3.1
Line:	2
Kind:	English
Problem:	
Proposed text:
Insert "the" before "extended"

Approved disposition: Accepted.

Seq no:	 36
Clause:	4.1.3.3.1
Line:	Note 1
Kind:	English
Problem:	
Proposed text:
Insert "the" before "portability", replace "program" with "programs", 
insert "the" before "same", replace "string and" with "strings and data 
of", "those" with "this", delete "to", replace "bad mannered program," 
with "programs, the", "can" with ?fould"

Approved disposition: Accepted.

Seq no:	 37
Clause:4.1.3.3.1	
Line:	Note 2
Kind:	Minor technical
Problem:	Duplicate of 4.1.3.7
Proposed text:
Delete note since it belongs better in clause 4.1.3.7

Approved disposition: Accepted.

Seq no:	 38
Clause:	4.1.3.3.2
Kind:	English
Proposed text:
Replace "in a" with "in an"

Approved disposition: Accepted.

Seq no:	 39
Clause:	4.1.3.3.3
Line:	Title
Kind:	English
Proposed text:
Replace "subtype" with "subtypes" and "type" with "types"

Approved disposition: Accepted.

Seq no:	 40
Clause:	4.1.3.3.3
Line:	Para 1
Kind:	English
Problem:	
Proposed text:
Delete "the particular", "particular" in line 2, insert "the" after
"If", 
replace "support" by "supports", insert "should be" before "permitted", 
"the" before "current", replace "inter-kind" by "inter-type"

Approved disposition: Accepted.

Seq no:	 41
Clause:	4.1.3.3.3
Line:	last
Kind:	Minor technical
Problem:	"current  FORTRAN" may not be correct  in future.
Proposed text:
Replace "current  FORTRAN standard" with the correct  dated reference
and include in clause 2.

Approved disposition: Accepted.

Seq no:	 42
Clause:	4.1.3.4
Kind:	English
Problem:	
Proposed text:
Insert "a" after "assumes", "for presentation" after "terminal", replace
"with" with "as", insert "or octet length" after "byte length", replace 
"also should...test" with "should also provide functionality to 
determine", insert "that" before "will"

Approved disposition: Accepted.

Seq no:	 43
Clause:	4.1.3.4.2
Kind:	English
Problem:	
Proposed text:
Insert "the" before "means"

Approved disposition: Accepted.

Seq no:	 44
Clause:	4.1.3.4.3
Kind:	English
Problem:	
Proposed text:
Replace "a" be "the"

Approved disposition: Accepted.

Seq no:	 45
Clause:	4.1.3.4.3
Kind:	Minor technical
Problem:	Example in definition.
Proposed text:
Move second sentence into a Note.

Approved disposition: Guideline rewritten.

Seq no:	 46
Clause:	4.1.3.6
Kind:	English
Problem:	
Proposed text:
Insert "an" before "extended"

Approved disposition: Accepted.

Seq no:	 47
Clause:	4.1.3.6
Kind:	Minor technical
Problem:	Text appears to mandate a method of specification for a 
standard.
Proposed text:
Add Note: The programming  language standard does not need to provide
this extended character  data type as a separate data type.

Approved disposition: Accepted.

Seq no:	 48
Clause:	4.1.3.6
Line:	Note 1
Kind:	English
Problem:	
Proposed text:
Replace "ought not to" with "should not", "should should" with "should" 
and delete "but not so strongly recommended"

Approved disposition: Accepted.

Seq no:	 49
Clause:	4.1.3.6
Line:	Notes 1
Kind:	Minor technical
Problem:	This appears to be specifying guidelines for the standard 
and so therefore  should not be a Notes. However it appears to be 
predicated on a view of programming  languages which does not apply to 
them all. Programming language should be allowed to handle composite 
sequences and therefore any guidelines should be about the issues in 
doing so, perhaps even providing a caution against doing this.
Proposed wording:
Needs major revision by WG20

Approved disposition: Rejected. SC22 Character set adhoc meeting
resolved that the composite sequence does not need to be recognized as a
unit for manipulation. The note simply says that for most programming
language, the composite sequence is not a single character. In the case,
if a programming language need to recognize the composite sequence as an
unit for manipulation, this TR suggest the data type for the unit
should not be CHARACTER. Currently no programming language recognize
the composite sequence as an unit, this guideline should not be in
main clause, but in a note.

Seq no:	 50
Clause:	4.1.3.6
Line:	Note 2 last line
Kind:	English
Problem:	
Proposed wording:
Insert "and from" after "to" (twice)

Approved disposition: Accepted.

Seq no:	 51
Clause:	4.1.3.6
Line:	Note 2
Kind:	Minor technical
Problem:	This is a guideline, not a note. However this guideline 
goes too far in suggesting solutions to the problem, since some
languages may not need to have separate data types.
Proposed wording:
Remove Note 2 header and Replace "standard should provide" with
"standard committee should consider the provision of"

Approved disposition: Accepted.

Seq no:	 52
Clause:	4.1.3.7
Kind:	English
Problem:	
Proposed wording:
Insert "the" after "If", "a" before "multi-byte", replace "character,"
with "characters,", "functionalities:" with "functionality:"

Approved disposition: Accepted.

Seq no:	 53
Clause:	4.1.3.7
Line:	a)
Kind:	Minor technical
Problem:	Over specifies guideline.
Proposed wording:
Delete "multi-octet"

Approved disposition: Accepted.

Seq no:	 54
Clause:	Annex A
Line:	Para 2 sentence 2
Kind:	Minor technical
Problem:	Unnecessary explanation which could be contentious.
Proposed wording:
delete sentence 2

Approved disposition: Accepted.

Seq no:	 55
Clause:	Annex A
Line:	para 3
Kind:	Specification too restrictive.
Problem:	
Proposed wording:
Insert "minimal set of" after "recommended"

Approved disposition: Rejected. The intention of the list in Annex A is
to allow the full ISO 10646 character repertoire except special symbols
for use in identifiers.

Seq no:	 56
Clause:	Annex D
Kind:	Minor technical
Problem:	Doesn't seem to be relevant
Proposed wording:
Delete, but include reference in Note in 4.1.3.6

Approved disposition: Accepted. Annex D will be deleted.

Seq no:	 57
Clause:	Annex D
Kind:	Minor technical
Problem:	Not relevant
Proposed wording:
Delete

Approved disposition: Accepted. The Annex D will be deleted.

Seq no:	 58
Clause:	Annex H
Kind:	Minor technical
Problem:	Too innovative and not thought through and stable enough
Proposed wording:
Delete unless adequate support from programming language standards 
committees is obtained.

Approved disposition: Accepted. The annex will be deleted.

#################################################

Denmark

O1. the handling of character support is not consistent throughout
the report.

Approved disposition: Accepted.  Rephrased.

O2. the handling of internationalization support is minimal,
and not to the level expected.  This especially in the light of
the recent failure of the NP for internationalization APIs.

Approved disposition: Rejected. WG20 is proposing a NP for
Internationalization APIs standard. The internationalization
support functionality will be standardized by the standard.
A future revision of TR 10176 will reference the 
Internationalization API standard.

E3. 3.6.2 byte, add "or other data" (a byte can store integers, or
parts thereof and also real etc.)

Approved disposition: Accepted. The basic character data type will
be replaced with OCTET data type, then the OCTET data type can
store any data.

O4. The terms 3.6.8 "basic character data type" and
3.6.10 "extended character data type" are misleading terms.
The basic type can handle extended character sets.
Rather call it something like multi-octet and widechar.

Approved disposition: Accepted. Instead of using basic and
extended character data type, CHARACTER and OCTET data type
will be used.

O5. 3.6.11 multi-byte representation and 3.6.12 multi-octet
representation are misleading terms. In common sense a UTF-8
string would be multi octet, but this is not the meaning here
(multi-octet is widechar only).

Approved disposition: UTF-8 may be stored in 1 to 6 
units of a data type whose bit length is one octet. The UTF-16 
is stored in 2 units with a bit length of two octets.
The term "multi-byte" is used for the data representation that
uses multiple units, regardless of bit length of the unit.
The term "multi-octet" is used for bit length of eight bit per unit.
In this sense, UCS-2 is multi-octet and single byte, UTF-8
is single-octet multi-byte, and the UTF-16 is multi-octet and
multi-byte.

E6. 3.6.13. "A presentation device with fized ..."
Add "The" before VGA. Is VGA defied?

Approved disposition: Accepted. WG20 think VGA is a commonly used
term.

E7. 3.6.14. Add an "s" in complicated shape characters.

Approved disposition: Accepted.

O8. 4.1.1 delete guideline k) and l) as they are out of scope
of this revision (which should only deal with i18n and charsets)

Approved disposition: Accepted.

E9. 4.1.3 second paragraph: replace "relating" with "relates".

Approved disposition: Accepted.

O10. 4.1.3 note 2 and 3, here we should rather use the distinction
on the coded character vs abstract character model of annex H.

Approved disposition: Rejected. The CHARACTER data type used in
the TR is coding independent. 

E11.4.1.3 Editors note: Should probably read
"Guideline: Use of other character sets" (note plural s on "sets".
Also in "programming language standards". Delete plural "s" on
character "sets" in line 5 of the paragraph. Insert "a" before
"wider" in line 6.

Approved disposition: Editor's notes will not remain in the
final text of the TR.

O12. 4.1.3.1.3 should indicate that the guideline is
valid for all subsets of 10646 and however the subset is coded.
The guideline now could be interpreted as only being valid for
10646 encoded strings.

Note 2 of 4.1.3.1.3 should be enhanced with recent developments in
the C++ and C working groups. That is also affecting annex D.

Approved disposition: Accepted. 

O13. 4.1.3.1.4 literals. this should depend on the terminology of
annex H, and when operating on the abstract level there there
is no reference to encoding (UCS-2 or UCS-4). The numbering scheme
could also be decimal instead of hex, as SGML and some programming
languages. A "u" in front of the numbers should be recommended.

Approved disposition: Partially accepted. The C++'s approach,
the form of escape characters followed by SC2's character short
identifier will be introduced.

O14. 4.1.3.1.4 literals. there should also be ways of representing
characters in literals that are not hexadecimal coded, as programming in
hex
is a bad programming style.

Approved disposition: Although the hex representation is not so
good practice, but is commonly used. Since the representation exist
in the approved previous edition of this TR, the representation
will remain in this edition. However, the approach of using
short character identifier as defined by SC2 will be introduced.

O15. 4.1.3.1.5 comments. This guideline should be more explicit
and allow all characters in comments, except for some special
characters and characters terminating the comment.

Approved disposition: Accepted.

O16. 4.1.3.3 character data types. This section should be replaced by
the concepts in annex H.

Approved disposition: Partially accepted. Those data types will be
described by using CHARACTER data type which is independent from
coding scheme, and OCTET data type.

E17. 4.1.3.4.1 Add "a" after "assumes". Use "as" instead of "with" in
"the same with".

Approved disposition: Accepted.

O18. 4.1.3.5 collating. Support for ISO/IEC 14651 should be recommended,
and also support for other collating sequence specifications,
as per POSIX and ISO/IEC 14652 (at CD consideration stage) .

Approved disposition: Future release of this TR may recommend
conformance level of IS 14652 when it is approved. 

O19. 4.1.3.6 and 4.1.3.7 should be rewritten in the light of annex
H and also new teminology ala widechar/multibyte.

Approved disposition: Rejected, since annex H will be removed.

E20. 4.1.4.1.7 assignments.
[d] should be reworded in light of annex H and new terminology

Approved disposition: Rejected since annex H will be removed.

O21. 4.7 should be enhanced with a recommended list of i18n
functionality, as per the scope of the revision of the TR.

Approved disposition: Rejected. The future revision of this TR 
will/may have guidelines based on the internationalization API
standard (proposed).

O22. B.1 i18n library. The TR needs to be enhanced by guidelines for
i18n functionality, as per the scope of the revision of the TR.

Approved disposition: Rejected. The future revision of this TR
will/may have guidelines based in the proposed internationalization
API standard. But the internationalization API is now in a quite
early stage, therefore it is impossible to provide detailed
guidelines in this edition. 

O23. C.1 10646 handling. The terminology in this annex is
not convenient and also confusing with the definitions given.
The annex should be revised in the light of annex H.

Approved disposition: Annex C will be removed.

O24. D.1 Should be reorded now that UTF-8 is full international
standard. Also this is only to be recommended at the I/O
boundary and a widechar model is to be recommended for
internal processing. See text in annex H.

Approved disposition: Annex D will be removed.

O25. D.2 extended identifiers. This annex should be revised
in light of recent developments in the C++ and C working groups.

Approved disposition: Annex D will be removed.

O26. multiple character set support. Should be enhanced
with previously provided text from Danish standards.

Approved disposition: Annex E will be removed.

O27. H - character types. Should be moved to the main text.

Approved disposition: Partially accepted. Although the annex H
will be removed, the character data type related clause in the
main body will be rewritten by using code independent CHARACTER
data type and OCTET data type.

##############################

COMMENTS ACCOMPANYING JAPAN NEGATIVE VOTE

PDTR registration:

   Japan approves the subject test in ISO/IEC JTC1/SC22 N2029
   "Concurrent PDTR Registration and PDTR Ballot for Revision of
   ISO/IEC TR 10176, Guidelines for preparation of programming language
   standards" to register as PDTR.

PDTR consideration:

   Japan disapproves the subject text in ISO/IEC JTC1/SC22 N202
   "Concurrent PDTR Registration and PDTR Ballot for Revision of ISO/IEC
   10176, Guidelines for preparation of programming language standards"
   as PDTR with the following comments.

   Japan will change its position to approve if the following comments
   are reasonably accepted.

   Comments:

   Source: Japan
   Status: National body position
   Date:   1996-05-21

   JAPAN-1
   Annex A  Extended repertoire for identifier
   Line 1
   Minor technical
   Problem: Since there are not so many programming language standard
            that allows outside of ISO/IEC 646 character repertoire
            for user-defined identifier, it is too advance to recommend
            all of programming language standard to support those
            repertoire. In this sense, the wording "The programming
            language standard should allow...." is too strong.

   Proposed text: Programming language standard should not prohibit
            characters outside of ISO/IEC 646 repertoire for
            user-defined identifier, as far as possible.
            The programming language standard should implementation
            allow to use outside of ISO/IEC 646 for user-defined
            identifier.

Approved disposition: Accepted.

   JAPAN-2
   Annex A  Extended repertoire for identifier
   Line 10-48
   Minor technical
   Problem: The table is based on ISO/IEC 10646-1:1993, but
            amendments of the standards also reached to AM and
            DAM stage. The table should be maintained based on
            the AM and DAM.

   Proposed text: Since the ISO/IEC 10646 will be enhanced
            continuously. In order not to chase a moving
            target, the characters that should not be allowed
            for user-defined identifiers, e.g. mathematics symbols,
            should be specified narratively, instead of listing
            the characters that should be allowed.

Approved disposition: Rejected. The annex is based on the
current AMs of ISO/IEC 10646. This annex is subject to be
revised in future revision of this TR.

   JAPAN-3
   Annex B  Guidelines for preparation of Internationalized library
   Line all
   Major technical
   Problem: Since the NP for Internationalized API has been
            voted down, the guidelines for the API does not needed.
            Each programming language standard should have free
            hand what kind of Internationalized API should be
            supported by the programming language, considering the
            user requirements to the language.

   Proposed text: Remove the annex.

Approved disposition: Accepted.

   JAPAN-4
   Annex C  Issues on ISO/IEC 10646 handling
   Line all
   Major technical
   Problem: The contents of the annex looks being duplicated with
            the body part of the PDTR. Therefore, this annex is not
            needed.

   Proposed text: Remove the annex.

Approved disposition: Accepted.

   JAPAN-5
   Annex D.1 File System Safe UTF (UTF-8)
   Line all
   Major technical
   Problem: Since the subject encoding is specified by the
            ISO/IEC 10646-1 as an amendment, the explanation of
            the encoding is not needed in this PDTR.

   Proposed text: Remove the annex.

Approved disposition: Accepted.

   JAPAN-6
   Annex D.2 A suggested mechanism to support extended repertoire
             for identifier.
   Line all
   Major technical
   Problem: Since the ISO/IEC JTC1/SC2 specifies short identifier
            of character, per request from JTC1/SC22. The technical
            contents of the annex should be replaced with the one
            that utilize the short identifier. Guidelines should be
            provided for the use of the short identifier, perhaps
            for the clause 4.1.3.1.3 (user-defined identifier) and
            for the clause 4.1.3.1.4 (character literal)

   Proposed text: Remove all text of annex D.2, then add new
            guidelines into 4.1.3.1.3 and 4.1.3.1.4, if required.
            C++'s approach might be explained there.

Approved disposition: Accepted.

   JAPAN-7
   Annex E  Multiple character set support
   Line all
   Major technical
   Problem: Since the contents of the annex is empty, this annex
            should be removed.

   Proposed text: Remove the annex.

Approved disposition: Accepted.

   JAPAN-8
   Annex H  Advanced data type for character and string handling
   Line all
   Major technical
   Problem: Since none of programming language mandated the
            support of those data types, the recommendation of
            those data types are too advance for the current
            technology.

            The guideline described in the PDTR should be implemented
            by multiple programming language standards. The guideline
            that has not yet implemented by any programming language
            standard or only applicable single language standard should
            be removed from this PDTR.

            This PDTR should only contains guidelines to meet minimum
            requirements applicable for every language, as the previous
            edition of the TR did. Every advanced technologies should
            be left to the responsible language WG's decision.

   Proposed text: Remove the annex.

Approved disposition: Accepted.

##############################

COMMENTS ACCOMPANYING NETHERLANDS NEGATIVE VOTE

.....................................................
22N2029  PDTR 10176 Revision
Guidelines for preparation of programming language
standards
96-05-26, NO WITH COMMENTS
......................................................
The Netherlands does not approve of PDTR 10176:1995 because in our
opinion, the current document does not show sufficient qualities to
be acceptable:

Comments

General

1.  The scope of the revision of TR 10176 (see for instance SC22/N1509)
  is to include guidelines on 2 topics: internationalization (based on
  the framework TR) and charactersets (specifically single-byte vs
  multi-byte issues in programming languages). However, guidelines for
  I18N are completely missing (presumably, because the framework is not
  ready). On the other hand in several places changes are proposed that
  are outside the scope of the revision (example: Introduction, 2nd
  paragraph after the note: it suggests to make the reason for
  non-adoption of a guideline available in an informative annex of the
  p.l. standard, rather than in the minutes of the meeting that made the
  decision.  Why?? The 2nd sentence of this paragraph (badly written:  the
  reason and the reason of the reason ???)  makes it only worse).
  Should a revision of 10176 be taken up, standards prepared by WG11
  should certainly be included.

Approved disposition: The framework document DTR 11017 explains
candidates
  of internationalization services but not all of them are relevant with
  programming language standard. This TR 10176 guided that the language
  culture dependent services which current programming language standards
  are supporting should be cultural convention set dependent, and the
  standards should provide a means to switch the cultural convention set
  dynamically. The TR allows programming language standards to have free
  hand what culture dependent service will be supported, therefore this
  TR has no guidance for the kinds of services that all programming 
  languages should support. WG20 also initiated NP for 
  internationalization API. It is intended that Internationalization API
  that should be commonly supported by programming languages will be
  specified by the standard, but the NP was failed. 
  
  Regarding informative annex v.s minutes, the original sentence of
  the first edition will be maintained. (Accepted.)

2.  The wording of the additions to the original 10176 frequently
  contains somewhat crippled English making it quite difficult to
  precisely understand the intended meaning. Several ambiguities and
  unclarities are noticeable (see in detailed comments).

Approved disposition: See approved disposition of each detail comment.

3.  The PDTR creates the impression that it tries to define terms and
  concepts regarding characters that are meant specifically for SC22.
  If this is accepted, nothing will resist other SCs, like SC18, to do
  the same thing. That languages like C and Pascal differ in their
  character concept is bad enough, but the PDTR should not add more
  confusion.  We might have expected from WG20 a proper piece of research
  with respect to the commonalties and differences between the various
  concepts of character in existing programming languages.

Approved disposition: WG20 believe that the concept/definition of
"character" used in this TR is consistent with SC2's one. 

4.  Programming languages have a long tradition of striving for
  precision in describing the language. Contrary to this principle, the
  PDTR abounds in vague and confused statements, which demonstrate,
  assuming proper understanding of the English, several misconceptions
  about data types, character sets and semantics. For examples, see
  detailed comments). We doubt whether the author(s) have properly
  studied ISO/IEC 11404, Language independent data types. It would have
  prevented them from introducing concepts unnecessarily deviating from
  those in an approved standard.

Approved disposition: Accepted. The character data type related
clause will be rewritten by using CHARACTER and OCTET data type
specified in ISO/IEC 11404.

5.  Several Annexes are attached which, insofar as not being marked for
  deletion in the DTR, contain extensive preludes on issues like
  cultural conventions and string ordering, for which standards may or
  may not appear in the future. We want all these Annexes to be deleted.

Approved disposition: Accepted except annex A.

To change our vote to positive we require a second PDTR, in which all
these defects have been repaired.

In addition the following more detailed comments are presented for
correction.

At 2. Reference (s missing):
ISO 6937-2:1983 : replace by ISO/IEC 6937:1994 and correct title.
(change this at all other occurrences)

Approved disposition: Accepted.

At 3.6 change title into:
Terms related to character coding and internationalization

Approved disposition: Accepted.

At 3.6.2 the definition of byte is not taken from SC2 standards, but
that for octet is. Why? This is causing confusion.

Approved disposition: A byte is not necessarily an octet. If character
data type is defined as multi-octet length, the storage unit of the
character data type can be called a byte.

At 3.6.3 change origination into organization, in the NOTE change to:
 -- The definition above is that from the standards developed by
ISO/IEC JTC1/SC2.

Approved disposition: Accepted.

At 3.6.7: This definition is utterly unclear.

Approved disposition: Detail comments that points out each unclear
definition will be highly appreciated.

At 3.6.11 and 3.6.12: These definitions are very confusing. They
suggest an essential difference between octet and byte which does not
exist.
What is described is not reflected in these names. What is presumably
meant is coding with a varying number of octets and coding with a fixed
number of octets. If so, say so.

Approved disposition: Rejected. The byte is not necessary an octet.
The byte could be 2 or 4 octet, in the case of UCS2, UCS4, and
UTF-16.

At 3.6.13, 3.6.14: Presentation issues are outside the scope of any
programming language standard. Remove.

Approved disposition: Accepted.

At 3.6.17: This is unclear and premature. Remove definition.

Approved disposition: Rejected. This definition comes from 
approved TR 11017.

At 3.7.1: Remove definition. If a term is not used, it shall not be
defined.

Approved disposition: Accepted.

At 4.1.3: Remove NOTE 2 and NOTE 3. Characters are not different
because their coding is different. These notes confuse the concepts
of character (which is code independent) and that of their coding.

Approved disposition: Rejected. The notes exist in the approved
first edition of this TR.

At 4.1.3.1.1, last sentence: Apart from the SPACE these characters
are control characters. The PDTR should use SC2 terminology.
 ---NOTE 1: This is an attempt to put the clock back. Restricting a
programming language to only one pair of brackets is a major block to 
efficient parsing of programs.
 ---NOTE 2: Change ISO 6937-2 to ISO/IEC 6937.
 ---NOTE 3: Change to UCS-2 or UCS-4 of ISO/IEC 10646-1, because it is
a Multiple-octet standard, not a 16-bit or 31-bit one.

Approved disposition: Note 1: Rejected. These sentence exist in
the first edition. Note 2: Accepted. Note 3: Accepted.

At 4.1.3.1.2: Does this mean that every PL standard should be
extended with an annex of more than 700 pages? Programming languages
should not define characters based on their shape.

Approved disposition: Rejected. COBOL standard recognize lower case
A, upper case A, and double-width A are identical if those character
is used in identifier.

At 4.1.3.1.3: Remove second sentence. Annex A is not based on
expertise on the scripts included (for example, it allows for Indian
scripts only consonants in identifiers, not vowels), and is to be
removed.
The guideline should specify that IF the p.l. supports additional
characters in an identifier, HOW this should be specified in the p.l., 
and probably how implementations should identify WHICH additional 
characters are available.
 ---NOTE 2: Remove second sentence. Annex D2 should go, too.

Approved disposition: The annex A will be corrected based on the
current AMs of ISO/IEC 10646. And the second sentence will be
rewritten.

At 4.1.3.1.4, a): Change to: The character is represented by its
graphic symbol, e.g. ...
 ---NOTE 2: Remove. What is "inside a program"?
 ---NOTE 4: Change ISO 6937-2 to ISO/IEC 6937.

Approved disposition: Rejected. Those exist in first edition
of this TR. 

At 4.1.3.2:
 ---NOTE 3: Remove. Annex C should go.

Approved disposition: Accepted.

At 4.1.3.3.1   ---Remove. This definition repeats an earlier one.

Approved disposition: The clause is rewritten.

At 4.1.3.3.2:  ---Remove. A datatype does not store anything.  What
is `a unit of the data type'?

Approved disposition: The clause will be rewritten by using data
repertoire that can be stored in the data type.

At 4.1.3.4.1:  ---Remove. Presentation matters are outside the scope
of a programming language standard.

Approved disposition: Accepted.

At 4.1.3.4.2:  ---Remove or rewrite. As it stands now, it is unclear.
It may pertain to program text or to input characters, which need not to
be
served by the same classifications.

Approved disposition: Accepted.  It pertains to input characters.

At 4.1.3.4.3:  ---Remove. It is unclear what `equivalent character
semantics' means. Furthermore, this matter may not be relevant to 
all programming languages.

Approved disposition: "equivalent character semantics" will be replaced
by other words.

At 4.1.3.6: Remove NOTEs 1 and 2. The matter is sufficiently
explained in ISO/IEC 10646-1 itself (4.13), and there is no need to 
repeat it here.

Approved disposition: Rejected. 

At 4.1.3.7: Remove. It confuses again the concepts of character and
coding.

Remove all Annexes. See above under General.

Approved disposition: Accepted except annex A.

___________________ end of document SC22 N2491 ______________________