Subject: N 3805-Canadian National Body Report to the SC 22 Plenary

From: Sally Seitz <[email-masked]>
Date: Mon, 6 Sep 2004 03:15:15 -0400

ISO/IEC JTC 1/SC22

Programming languages, their environments and system software interfaces

Secretariat:  U.S.A.  (ANSI)

ISO/IEC JTC 1/SC22 N 3805

TITLE:

Canadian National Body Report to the SC 22 Plenary

DATE ASSIGNED:

2004-09-06

SOURCE:

Canadian National Body

BACKWARD POINTER:

DOCUMENT TYPE:

National Body Contribution

PROJECT NUMBER:

STATUS:

Pending approval of the addition of this document to the SC 22 Plenary
agenda, it will be reviewed under agenda item 7.1.  

ACTION IDENTIFIER:

FYI

DUE DATE:

DISTRIBUTION:

Text

CROSS REFERENCE:

DISTRIBUTION FORM:

open

Sally Seitz

ANSI

25 West 43rd Street

New York, NY  10036

Telephone:  (212) 642-4918

Fax:             (212) 840-2298

Email:  [email-masked]

___________________________end of cover page, beginning of
document_________________________________

         Canadian Report to ISO/IEC/JTC1/SC22 Plenary 

             September 2004

Canada Mirrors SC22 with Canadian Advisory Committee JTC1-SC22

(CAC-JTC1-SC22), a member of the Standards Council of Canada. 

CAC-JTC1-SC22 meets quarterly. Canada is active in WG3 APL, WG5

Fortran, WG9 Ada, WG14 C, WG15 POSIX, WG20 Internationalization, WG21

C++ and the Linux Rapporteur Group. For the 2004 plenary, we raise the

following issues.

LINUX

Resolution 14 from the Tokyo LRG meeting stated that

the LRG had completed its assigned tasks. Although there are costs 

associated with the maintenance of the LRG, there are still numerous

issues regarding the standardization of Linux that need further

discussion. 

It has become clear that multiple PAS submissions from

the Free Standards Group (FSG) will be needed to add new features

and address problems as they arise.  For example, see the discussion

arising from the following message

       <http://gcc.gnu.org/ml/gcc/2004-07/msg01337.html>. 

This ultimately led to a decision by the FSG to move C++ to a module 

that will still be required for LSB 2.0 but not submitted to

ISO/IEC/JTC1 as part of a PAS submission this fall 

      <http://gcc.gnu.org/ml/gcc/2004-08/msg00248.html>. 

Given that the LSB is a binary standard, it is possible that this

approach would cause ISO/IEC/JTC1 member countries to reject the PAS

submission, or that frequent updates to the whole document will need to be
done

as soon as the changes to different parts are available, leading to reduced
stability of the parent document and reduced acceptance on the part of users
of

the specification.

It is clear that the LSB is too large and unwieldy to be managed as

a single standardization unit.  It is our opinion that modularization

of the document would be useful to address this problem, and to 

facilitate the review process. 

We further note that PAS submissions are not subject to the same

convergence and formatting requirements as other ISO

standards.  Normally, it is expected that these issues are addressed as

part of the amendment process.  It is likely that the LSB 3.0

will be submitted in 2005 to address the shortcomings that have

developed with respect to the LSB 2.0, and LSB 4.0 12 months to 18

months later.  Following this process, each PAS submission will be

obsolete before they come up for renewal, avoiding the JTC1 amendment

process and failing to address document issues such as duplicate

specification of POSIX interface.

To date, JTC1 and SC22 do not have a process to deal with the

convergence, compatibility and formatting issues that arise as we try

to integrate the LSB into the ISO framework.  LRG resolution 12

concerned risk mitigation, specifically recommendation

12.1 urged SC22 to work with the FSG to ensure that emerging

technologies are not prematurely specified.  This is a difficult

problem, particularly when it comes to the standardization of open

source software. 

We are also concerned about the apparent reliance of JTC1 and SC22

upon FSG as the only resource for Linux-based standardization.  We note

that FSG does not have a mandate to represent the projects within the

open source community to standardize.  Further, the needs of its

membership may not reflect the viewpoint of the open source

maintainers.  Thus, it is possible that there will be a lack of close

cooperation between the FSG and project maintainers in the

specification development process.  Open source maintainers from the

areas covered by the LSB specification were not well represented at

either the London LSG or Tokyo LRG meetings.  As a result, there was

very little discussion of areas of the LSB that might be controversial

or premature, aside from POSIX.  The problems with C++ have been known

for over a year; however, it wasn't until an objection was raised

by the C++ library maintainer on the GCC list that any movement

occurred in the position of the FSG.  SC22 needs to work harder in this
area. 

It is Canada's position that the Linux Rapporteur Group should become

a WG with a mandate to develop documents for the Linux Standardization

process, to work with the LSB to improve the products being delivered,

and to give voice to those important people in the Linux process who

are being marginalized by the current process. Failing the formation

of a WG, at a minimum the LRG must be continued to report  on issues

in the following areas:

  1) Convergence and formatting of PAS submissions with other ISO

     standards; 

  2) Rationalization of the LSB with other standards, such as POSIX,

     and C++;

  3) Modularization of the LSB and other "Linux" standards.;

  4) Risk mitigation with respect to future LSB submissions; and 

  5) Developing policies as to the appropriate pace for updates in an

     area that is developing rapidly. 

POSIX

It is clear that all attempts to reform WG15 have failed. SC22 has not

had a valid report from WG15 in more than 3 years, and it is our

understanding that WG15 has not met for more than 3 years and that

the convener does not respond to requests for clarification.

It is troubling, however, that the Austin Group is continuing to submit

documents to JTC1 as though the relationship with WG15 is sound and

WG15 is a functioning entity. Furthermore, it is our understanding

that some members of WG15 may be attending Austin Group meetings as

ISO/IEC/JTC1/WG15 representatives.

It is Canada's position that WG15 has ceased to exist as a

functioning body, and that all work associated with WG15 reverts to

SC22. Furthermore, it is our position that SC22 has no current liaison

or participation in the Austin Group, and that either a new

relationship must be negotiated, or the Austin Group must be

terminated and the Open Group must apply as a PAS submitter to JTC1.

WG20 - Internationalization

With the moving of the SC22/WG20 ordering project to SC2, participation in
person at WG20 has dropped significantly. This concerns us as the need for
standardizing i18n functionality is still as significant as it was when WG20
was created, although focus in WG20 has been put from the beginning on
sorting.

We believe that SC22 should have a TR project in WG20 to survey all
functionalities currently in all programming language standards and
environment standards (such as POSIX and Linux). Such a project should
identify missing functionality and forecast future needs. Such a project
would require close coordination with and input from all other SC22 WG's.

Sally Seitz

Program Administrator

ANSI

25 West 43rd Street

New York, NY 10036

Phone: (212) 642-4918

Fax: (212) 840-2298