Subject: SC22 N3047 - Vote Summary on Approval of FPDAM2 to IS 9945-1: POSIX Shell and Utilities

From: William Rinehuls <[email-masked]>
Date: Tue, 14 Dec 1999 18:32:09 -0500 (EST)

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

TITLE:
Summary of Voting on FPDAM Ballot for FPDAM2 to ISO/IEC 9945-2:
Information technology - Portable Operating System Interface (POSIX) -
Part 2: Shell and Utilities

DATE ASSIGNED:
19199-12-13

SOURCE:
Secretariat, ISO/IEC JTC 1/SC22

BACKWARD POINTER:
N/A

DOCUMENT TYPE:
Summary of Voting

PROJECT NUMBER:
JTC 1.22.41

STATUS:
WG15 is requested to prepare a Disposition of Comments Report and make a
recommendation on the further processing of the FPDAM.

ACTION IDENTIFIER:
FYI to SC22 Member Bodies
ACT to WG15

DUE DATE:
N/A

DISTRIBUTION:
Text

CROSS REFERENCE:
N2972

DISTRIBUTION FORM:
Def

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

__________ end of title page; beginning of overall summary ____________

                      SUMMARY OF VOTING ON

Letter Ballot Reference No:  SC22 N2972
Circulated by:               JTC 1/SC22
Circulation Date:            1999-08-10
Closing Date:                1999-12-10

SUBJECT:  FPDAM Ballot for FPDAM 2 to ISO/IEC 9945-2: Information
          technology - Portable Operating System Interface (POSIX) - Part
          2: Shell and Utilities

------------------------------------------------------------------------

The following responses have been received on the subject of approval:

"P" Members supporting approval
          without comments                    10

"P" Members supporting approval
          with comments                        1

"P" Members not supporting approval            2

"P" Members abstaining                         1

"P" Members not voting                         7

"O" Members supporting approval
          without comments                     1

----------------------------------------------------------------------
Secretariat Action:

The comments accompanying the negative votes from Norway and Japan are
attached.

The comment accompanying the affirmative vote from the United States of
America was:  "The draft of the document used for the FPDAM 2 ballot
should be the same P1003.2b document that is submitted to the IEEE
Standards Board in order to maintain the agreed upon synchronization."

WG15 is requested to prepare a Disposition of Comments Report and make a
recommendation on the further processing of the FPDAM.

________ end of overall summary; beginning of detail summary __________

                 ISO/IEC JTC1/SC22  LETTER BALLOT SUMMARY

PROJECT NO: JTC 1.22.41

SUBJECT:  FPDAM Ballot for FPDAM2 to ISO/IEC 9945-2: Information
          technology - Portable Operating System Interface (POSIX) - Part
          2: Shell and Utilities

Reference Document No:  N2972           Ballot Document No:  N2972
Circulation Date:  1999-08-10           Closing Date:  1999-12-10
                                                              
Circulated To: SC22 P, O, L             Circulated By: Secretariat

                  SUMMARY OF VOTING AND COMMENTS RECEIVED

                  Approve  Disapprove  Abstain Comments   Not Voting
'P' Members

Austria             ( )      ( )         ( )       ( )       (X)
Belgium             (X)      ( )         ( )       ( )       ( )
Brazil              ( )      ( )         ( )       ( )       (X)    
Canada              (X)      ( )         ( )       ( )       ( )
China               ( )      ( )         ( )       ( )       (X)
Czech Republic      (X)      ( )         ( )       ( )       ( )
Denmark             (X)      ( )         ( )       ( )       ( )
Egypt               ( )      ( )         ( )       ( )       (X)
Finland             (X)      ( )         ( )       ( )       ( )
France              ( )      ( )         (X)       ( )       ( )
Germany             (X)      ( )         ( )       ( )       ( )
Ireland             (X)      ( )         ( )       ( )       ( )
Japan               ( )      (X)         ( )       (X)       ( )
Netherlands         (X)      ( )         ( )       ( )       ( )
Norway              ( )      (X)         ( )       (X)       ( )
Romania             ( )      ( )         ( )       ( )       (X)
Russian Federation  (X)      ( )         ( )       ( )       ( )
Slovenia            ( )      ( )         ( )       ( )       (X)
UK                  (X)      ( )         ( )       ( )       ( )
Ukraine             ( )      ( )         ( )       ( )       (X)
USA                 (X)      ( )         ( )       (X)       ( )

'O' Members Voting

Korea Republic      (X)      ( )         ( )       ( )       ( )

______ end of detail summary; beginning of Norway comments ____________

From: Ulf Leirstein <[email-masked]>

Subject: Norwegian vote on N2972

Norway vote NO to this document.

The following are the Norwegian comments accompanying the Norwegian
negative vote on SC22 N2972, POSIX-2 PDAM (.2b)

1. General comments:
NOR.1 The disposition of comments in N2971 has not been implemented
fully, as the accepted Danish comment on "substitute" has not been
implemented. The text that was proposed and accepted (possibly 1003.2/D8
section 2.5.2.2) has not been incorporated in the PDAM.

2. Technical comments

NOR.2 There should be a repertoiremap description file format, to
describe which repertoire is covered and how symbolic character names
relate to IS 10646.  This file describes the concept of character
repertoire of SC2 and lists abstract characters, (not encoded
characters as in charmaps). This concept is used in the cultural registry 
of ISO/IEC 15897 adn in PDTR 14652 and also (without the specific name of
repertoire map) in The Open Group registry.The concept of charmaps using
IS 10646 position values should be removed thruout, eg in 2.4.1.

NOR.3 The specification should be aligned with the specifications in PDTR 
14652.

NOR.4 WIDTH, WIDTH_VARIABLE, WIDTH_DEFAULT statements sould be localetd
in the locale definition, as they are related to abstract characters.
Abstract characters are defined in IS 10646, and a number of attributes
to the abstract characters are also defined here, including WIDTH
attributes. Thus for an abstract character, with double width, this has
the width 2 regardless of the encoding, be it in IS 10646 or a national
double-byte encoding. The LC_CTYPE category should be practically
identical for all locales so there is no overhead in doing this once and
for all in a standard locale, that then others can refer to.
As the WIDTH attribute is an attribute of an abstract character and not 
related to encodeing, it is a big architectural mistake to move it into
the encoding specification of the charmap, and destroying the principle
of making locales contain all encoding independent information.

NOR.5 2.5.2.2.4 The coding of NUL should be removed as a requirement, as 
this requirement has been removed in the new C standard.

NOR.6 4.35

We should use the repertoiremap files as requested in NOR.2

The repertoiremap files should be used on the localedef command line to
in a well-defined way be able to use locales and charmaps using diferent
symbolic character notations. Two new options are proposed:

     -l repertoire_name       Specify the name of a
                              repertoiremap for mapping the
                              locale symbolic character names
                              to IS 10646

     -r repertoire_name       Specify the name of a
                              repertoiremap for mapping the
                              charmap symbolic character names
                              to IS 10646

The -u option should be removed as the above covers the same
functionality in a much more well defined way, and as much data
for this is available.

A naming convention should be introduced to reference standard locales, 
charmaps and repertoiremaps from the international cultural conventions
registry, for example introduced by the three letters "std".

NOR.7

Line 1915: the name should be "codeset" not "charset" - we are talking 
about coded character sets, not the character sets which is without
coding, acording to SC2 terminology.

NOR-8
Line 1921: Please use "UTF-8" instead of "UTF8", also other places, as
this is the officual name in IS 10646.

NOR.9
P 288 line 633ff: please change "glyph" to "anstract character" as glyph 
means something else in ISO (=shape)

NOR.10
Please change all references to IEEE std's to corresponding ISO/IEC 
standards.

End of comments

@ D.1 c 8

Annex D: a new RFC is available in RFC 1521

____ end of Norway comments; beginning of Japan comments ________________

ISO/IEC                            Vote on PDAM2 to IS 9945-2
                                   Date of Circulation:      1999-08-10
                                   Closing date for voting:  1999-11-10
                                  
                                   Reference number:
                                   ISO/IEC JTC 1/SC22 N2972

------------------------------------------------------------------------
P-members have an obligation to vote
------------------------------------------------------------------------
ISO/IEC JTC 1/SC22

Title:  Programming languages, their environments and system software
        interfaces

Secretariat:  U.S.A.  (ANSI)

------------------------------------------------------------------------
Please send this form, duly completed, to the secretariat indicated above.
------------------------------------------------------------------------

CD:     PDAM2 to ISO/IEC 9945-2

TITLE:  PDAM2 to ISO/IEC 9945-2: Information technology - Portable
        Operating System Interface (POSIX) - Part 2: Shell and Utilities

-------------------------------------------------------------------------

Please put an "X" in the appropriate box(es)

Approval of the draft:

_____  as presented

_____  with comments as given below (use separate page if necessary)

       _____  general
       _____  technical
       _____  editorial

__X__  Disapproval of the draft for reasons below (use separate page as
       annex, if necessary)

       __X__  Acceptance of these reasons and appropriate changes in the
              text will change our vote to apoproval.

_____  Abstention (for reasons below)

-------------------------------------------------------------------------
P-member voting    JAPAN
Date:   99-12-10     Signature (if mailed)
_________________________________________________________________________

Japan will change it position from disapproval to approval if
 the syntax to define user defined character mapping in the
 localedef utility, that will be referred to by wctrans() and
 towctrans() functions specified by the ISO/IEC 9899 (C language)
 Amendment 1, will be added.

 The initial Japanese proposal on this issue, contributed in 1996
 was as follows:

| [Attachment: LC_CTYPE extension proposal for locale-specific character
mapping]
|
|
| Source:  Japan
|
| Title:   Japanese proposal to POSIX.2b on LC_CTYPE extension for
|          locale-specific character mapping
|
| Status:  Japanese position
|
| Short description:
|          Japan proposes that LC_CTYPE locale definition should be
|          extended to allow locale-specific character mappings
|          to be specified. This extension is necessary to implement
|          wctrans() and towctrans() functions in ISO C amendment
|          on a POSIX conforming system.
|
| Text of contribution:
|
| ----------------------------------------------------------------------------
| [Note: The page numbers refer to the ones of P1003.2/D10.]
|
| Sect 2.5 (Locale) PROPOSAL.                 Page 8-9,12:
|
| Problem:
|     The LC_CTYPE (2.5.2.1) locale definition should be enhanced to allow
|     user-specified additional character mapping, similar in the concept
|     to the user-specified additional character class. In the Amendment
|     of ISO C standard, extended character mapping functions
|     (wctrans/towctrans) are specified. The following proposed extension
|     will serve for the machinery to define locale specific character
|     mappings used by the functions. Without having this extension,
|     POSIX conforming systems need to have their own extensions to
|     implement ISO C Amendment specifications.
|
| Proposal:[LC_CTYPE extension for specifying character mapping]
|
|     The proposed extension for character mapping is similar to the extension
|     of character class, which is already specified in .2b draft.
|     New keyword 'charconv' is introduced to define locale-specific
|     character mappings instead of 'charclass' keyword for character class.
|     The way of defining character mapping is not extended with this proposal.
|     The same specification for toupper/tolower mapping can be used for
|     locale-specific character mappings.
|
|     EXAMPLE:
|
|         LC_CTYPE
|
|         # define the names of locale-specific character mappings
|         charconv tojkata;tojhira
|
|         # tojkata: hiragana => katakana mapping
|    tojkata (<j0401>,<j0501>);(<j0402>,<j0502>);\
|                 .....definition.....
|
|         # tojhira: katakana => hiragana mapping
|         tojhira (<j0501>,<j0401>);(<j0502>,<j0402>);\
|                 .....definition.....
|
|    END LC_CTYPE
|
| [Proposed extension to .2b text]
|
| [Page 8]
| => 2.5.2.1 LC_CTYPE. Add the following keyword items after the item
|    labeled tolower:
|
|     charconv  Define one or more locale-specific character mapping names as
|               strings separated by semicolons. Each named character mapping
|               can then be defined subsequently in the LC_CTYPE definition.
|               A character mapping name shall consist of at least one and at
|               most fourteen bytes of alphanumeric characters from the
|               portable filename character set. The first character of a
|               character mapping name cannot be a digit. The name cannot
|               match any of the LC_CTYPE keywords defined in this standard.
|
|     charconv-name
|               Define the named locale-specific character mapping.
|               In the POSIX Locale, the locale-specific named character
|               mapping need not exist.
|
|               If a mapping name is defined by a charconv keyword, but no
|               character mappings are subsequently assigned to it, this
|               is not an error; it shall represent a mapping without any
|               character pairs belonging to it.
|
| [Page 12]
| => 2.5.3.1 Locale Lexical Conventions. Add the following token description:
|
|     CHARCONV  A string of alphanumeric characters from the portable
|               character set, the first of which shall not be a digit,
|               consisting of at least one and at most fourteen bytes,
|               and optionally surrounded by double-quotes.
|
| [Page 12]
| => 2.5.3.2 Locale Grammar. Modify the ctype_keyword and charconv_keyword
|    descriptions as follows:
|
|    ctype_keyword        : charclass_keyword charclass_list EOL
|                         | charwidth_keyword charclass_list EOL
|                         | defwidth_keyword defwidth_value EOL
|                         | charconv_keyword charconv_list EOL
|                         | 'charclass' charclass_namelist EOL
|                         | 'charconv' charconv_namelist EOL
|                         ;
|
|    charconv_namelist    : charconv_namelist ';' CHARCONV
|                         | CHARCONV
|                         ;
|
|    charconv_keyword     : 'toupper' | 'tolower'
|                         | CHARCONV
|                         ;
|

___________________________ end of SC22 N3047 _______________________