PROPOSAL FOR A NEW WORK ITEM
 
Date of presentation of proposal: 
2002-01-07
Proposer: 
German NB
Secretariat: 
ANSI
ISO/IEC JTC 1/SC 22  N 3356 

A proposal for a new work item shall be submitted to the secretariat of the ISO/IEC joint technical committee concerned with a copy to the ISO Central Secretariat.

Presentation of the proposal - to be completed by the proposer Guidelines for proposing and justifying a new work item are given in ISO Guide 26.
 
Title
Specification for additional character data types to the programming language C.
Scope
To introduce additional character data types and corresponding character and string literals to the programming language C (as defined in ISO/IEC 9899:1999). This will allow support for encodings such as UTF-16 in a portable way, examples will be included to show the use of these new data types. The relationship between the existing (char and wchar_t) character data types and the new types will be explained, a rationale for the choices made will also be documented.
Purpose and justification
The programming language C as specified by the International Standard ISO/IEC 9899:1999 provides two data types for character processing: char and wchar_t. For these data types a set of library functions is also specified. 

Current data processing systems have to be able to support many natural languages. This requires character sets that comprise more characters than can be represented in a single byte. Common approaches are to use a variable number of bytes for each character or to base the character encoding on 16-bit or 32-bit units. 

The C Standard requires that the type wchar_t be capable of representing any character in the current locale. However, a minimum width is not guaranteed. On the other hand, the width of wchar_t may be large, implying excessive memory requirements for application programs. In multi-user environments, as well as on mobile devices, memory is limited. Additional memory overhead means that cache limits will be exceeded more often and paging will occur more frequently. 

Using wchar_t, the portability of programs is limited since the width is platform-dependent. 

Some other programming languages support encodings based on 16-bit units or even use them as the processing character set. A number of database systems and some other commercially important software products offer APIs for UTF-16. UTF-16 is also a viable choice when migrating from UCS-2 implementations. When UTF-8 is used, byte-oriented APIs are sufficient, but for almost every commonly used language, the complexity of variable width characters shows up, except for the characters in the 7-Bit ASCII range. 

This work does not seek to change or invalidate the support for character sets currently used in C and C++ programs, but to make sure that portable support for a range of additional encodings is possible, including UTF-16. 

It is not proposed to define these additional character data types and corresponding character and string literals in an Amendment to the C standard but as a Technical Report type 2, which can at a later stage, and if deemed relevant, be included in the C standard as a new part or (normative of informative) annex.

Programme of work

If the proposed new work item is approved, which of the following document(s) is (are) expected to be developed? 
____ a single International Standard more than one International Standard (expected number: ........ ) 
____ a multi-part International Standard consisting of .......... parts 
____ an amendment or amendments to the following International Standard(s) .................................... 
_X__ a technical report , type 2 

Relevant documents to be considered
  • ISO/IEC 9899:1999 - Programming Language C
  • ISO/IEC JTC 1/SC22 WG14 N962 - Proposal for a work item - Additional character types
  • ISO/IEC 11404:1996 - Language-independent datatypes.
  • Cooperation and liaison
    All ISO/IEC JTC 1/SC22 Working groups that have an interest in supporting many natural languages, especially ISO/IEC JTC 1/SC22 WG21 (C++).
    Preparatory work offered with target date(s)
    A PDTR document will be ready for registration 24 months after the approval of the project by JTC 1.
    Signature:
    Siegfried Badenmüller 
    for
    German National Body - DIN
    P-Member of JTC 1/SC 22 
    Will the service of a maintenance agency or registration authority be required? .......NO............. 
    - If yes, have you identified a potential candidate? ................
    - If yes, indicate name .............................................................

    Are there any known requirements for coding? ..........NO.........
    -If yes, please specify on a separate page

    Are there any known requirements for cultural and linguistic adaptability? .....NO....
    - If yes, please specify on a separate page

    Does the proposed standard concern known patented items? .......NO..........
    - If yes, please provide full information in an annex

    Comments and recommendations of the JTC 1 Secretariat - attach a separate page as an annex, if necessary
     
    Comments with respect to the proposal in general, and recommendations thereon:
    It is proposed to assign this new item to JTC 1/SC22 WG14
    The proposed project editor is Nobuyoshi Mori (nobuyoshi.mori@sap.com) of Germany 

    Voting on the proposal - Each P-member of the ISO/IEC joint technical committee has an obligation to vote within the time limits laid down (normally three months after the date of circulation).
     
    Date of circulation
    2002-01-10
    Closing date for voting: 
    2002-04-11
    Signature of SC 22 Secretary:
    Matt Deane



    NEW WORK ITEM PROPOSAL - PROJECT ACCEPTANCE CRITERIA    
    Criterion Validity Explanation
    A Business Requirement    
    A.1 Market Requirement Essential ___
    Desirable ___
    Supportive ___
     
    A.2 Regulatory Context Essential ___
    Desirable ___
    Supportive ___
    Not Relevant ___
     
    B. Related Work    
    B.1 Completion/Maintence of current standards Yes ___
    No___
     
    B.2 Commitment to other organization Yes ___
    No___
     
    B.3 Other Source of standards Yes ___
    No___
     
    C. Technical Status    
    C.1 Mature Technology Yes ___
    No___
     
    C.2 Prospective Technology Yes ___
    No___
     
    C.3 Models/Tools Yes ___
    No___
     
    D. Conformity Assessment and Interoperability    
    D.1 Conformity Assessment Yes ___
    No___
     
    D.2 Interoperability Yes ___
    No___
     
    E. Other Justification    


    Notes to Proforma

    A. Business Relevance. That which identifies market place relevance in terms of what problem is being solved and or need being addressed.

    A.1. Market Requirement. When submitting a NP, the proposer shall identify the nature of the Market Requirement, assessing the extent to which it is essential, desirable or merely supportive of some other project.

    A.2 Technical Regulation. If a Regulatory requirement is deemed to exist - e.g. for an area of public concern e.g. Information Security, Data protection, potentially leading to regulatory/public interest action based on the use of this voluntary international standard - the proposer shall identify this here.

    B. Related Work. Aspects of the relationship of this NP to other areas of standardization work shall be identified in this section.

    B.1 Competition/Maintenance. If this NP is concerned with completing or maintaining existing standards, those concerned shall be identified here.

    B.2 External Commitment. Groups, bodies, or fora external to JTC1 to which a commitment has been made by JTC for cooperation and or collaboration on this NP shall be identified here.

    B.3 External Std/Specification. If other activities creating standards or specifications in this topic area are known to exist or be planned, and which might be available to JTC1 as PAS, they shall be identified here.

    C. Technical Status. The proposer shall indicate here an assessment of the extent to which the proposed standard is supported by current technology.

    C.1 Mature Technology. Indicate here the extent to which the technology is reasonably stable and ripe for standardization.

    C.2 Prospective Technology. If the NP is anticipatory in nature based on expected or forecasted need, this shall be indicated here.

    C.3 Models/Tools. If the NP relates to the creation of supportive reference models or tools, this shall be indicated here.

    D. Any other aspects of background information justifying this NP shall be indicated here.

    D. Conformity Assessment and Interoperability

    D.1 Indicate here if Conformity Assessment is relevant to your project. If so, indicate how it is addressed in your project plan.

    D.2 Indicate here if Interoperability is relevant to your project. If so, indicate how it is addressed in your project plan.