Subject: Document SC22 N2245

From: "william c. rinehuls" <[email-masked]>
Date: Mon, 19 Aug 1996 13:04:33 -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
N2245

August 1996

TITLE:                United Kingdom Contribution on Effective Management
                      of SC22 Projects

SOURCE:               Secretariat, ISO/IEC JTC 1/SC22

WORK ITEM:            N/A

STATUS:               N/A

CROSS REFERENCE:      SC22 N2129, N2228

DOCUMENT TYPE:        United Kingdom Contribution

ACTION:               To SC22 Member Bodies for information.

                      THIS DOCUMENT WILL BE DISCUSSED UNDER AGENDA
                      ITEM 11.2 AT THE SEPTEMBER 1996 JTC 1/SC22
                      PLENARY.

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]

__________________________________________________________________________ 
From:  "Stride, Jean" <[email-masked]>

UK Contribution on Effective Management of SC22 Projects

Programming and Specification Languages

In applying the principles of N2129 (JTC1 N4079) to SC22 
projects, the following points should be taken into account.

1. Unlike most standards, programming (and specification) language 
standards apply to two kinds of product: implementations of the 
language, and programs written in the language.  A producer of the 
second kind of product is a consumer/user of the first kind of 
product.  For each installed copy of an implementation there will 
correspond possibly dozens of programs.  For each implementation 
there will correspond hundreds if not thousands of programs.  
Hence a standard for a "minority" language of apparently low 
"market validity", as measured by number of implementations, can 
benefit many businesses and organisations, and large numbers of 
individuals (both programmers, and users of the programs they write).

2. There are many languages with significant levels of use 
world-wide, only a limited number of which are the subject of SC22 
projects.  Commonly, the demand for a standard has arisen within 
the community of language users and implementers themselves who 
have then provided the resources to produce it.  SC22 language 
standards can therefore be regarded as having been pre-selected 
for "market validity".

3. Languages are in general complex entities and the standards 
for them are correspondingly large and complex.  This accounts for 
the usually long period between establishment of the standards 
project and publication of the standard, but it also means that a 
considerable time is likely to elapse before there is a visible 
impact on the relevant market area - measured in years rather 
than months.  Implementations take time to produce, training 
courses take time to develop, text books take time to write and 
to publish.  Even once these have appeared, take-up is likely 
to be gradual since the uses within the language community will 
have different migration patterns, depending on their needs.  
Any assessment of "market validity" of a language standard must 
take account of them.

4. Languages are, on the whole, general purpose tools.  Even if 
originally designed for particular purposes, experience in the 
use of a language often leads to its application in unanticipated 
ways.  Many factors are involved in this, and standardisation is 
one.  This adds to the difficulty of assessing or predicting 
"market validity".

5. Once established, languages are, in IT terms, long-lasting.  
Implementations change as the platforms on which they run change, 
programs change (usually more slowly) as user needs change, but 
the languages themselves continue.  They get revised, to reflect 
new needs and expectations, but in essentials remain unchanged.  
This too means that SC22 projects need to be judged over a much 
longer timescale than is likely to be expected for many JTCI 
projects.

6. SC22, and its predecessor TC97/SC5 which itself grew out of 
TC97 ad hoc group E, has a history which can be traced back 
continuously to the very beginning of IT standardisation in the 
early 1960s.  SC22's long history and the longevity of its 
standards has led it to face questions of management, maybe earlier 
than most. This long experience, often hard-won, has been 
passed on over the years and some of it has been captured in 
sets of guidelines, published as TRs and hence available for new 
projects within SC22 and for projects of a similar nature 
elsewhere.  Management in the sense of N2129 has been learned 
and exercised in SC5/SC22 for over twenty years.  It has always 
operated in the market, i.e. the programming languages community, 
and its language standard projects have always been conducted 
with good visibility within that community.

7.  SC22 closes down further development in certain projects 
- e.g. for PL/I, Full Basic and Pascal - and disbanded the relevant 
WGs.  (The same had done for Algol 60 before it got withdrawn altogether.)
Usually, a residual project editor is left to handle any queries.  
This allows interpretation requests to be answered and in principle 
would permit technical corrigenda to be issued, but no more.  Any 
further development of any of these would require an NP to JTC1 which 
would be likely to fail.  We do not regard it as acceptable in our 
area to cancel a project completely once development stops:  
unfashionable, apparently  "faded away" languages do still have 
sizeable user communities, long after one might think there would be 
any need for the standards.   This again is a consequence of 
languages being long-lived, having many users, and having millions 
of lines of legacy code still in use.  The cost of keeping such 
"faded away" standards in being is negligible, yet is still valuable 
to the user communities concerned.

8.  SC22 does withdraw projects that have genuinely "faded away", 
e.g. by recommending withdrawal of the standards for Algol 60 and 
Minimal Basic, though this happens only when it is known that there 
is no remaining benefit.

9. SC22 routinely conducts consultative letter ballots within the 
SC on proposals for new projects or project extensions.  Project 
divisions to produce multipart documents are scrutinised by SC22 
(though the UK would like this scrutiny to be more rigorous in 
future).

General

The danger of the "market validity" appraoch is that it may be 
applied too crudely, simply using the things that are obvious and 
relatively easy to measure.  Point 1 above shows that the number 
of conforming implementations of a standard is not an adequate 
measure.  Even if there are no conforming implementations at all, 
conforming programs will still in general be easier to move to a 
different platform, since they will not use vendor-specific 
features.  With a particular non-conforming implementation, the 
standard provides a yardstick against which it can be measured: 
programs rarely use all parts of the language, so any parts that 
are not correctly implemented can often be avoided, or the 
effects documented and allowed for.

Sales of a standard are also not an adequate criterion:  high 
sales certainly denote validity but low sales do not necessarily 
mean lack of validity.  Language standards are large, complex 
documents, and hence extremely expensive.  Many users cannot 
justify the expense: programmers learn from textbooks that teach 
the standard language, or courses, or using a conforming 
implementation and its documentation.  Furthermore, using the 
standard promotes shared learning and transfer of skills, even 
without any conforming implementations.

All these substantial economic benefits contribute to the market 
validity of a standard and need to be taken into account.

Other Projects

SC22 is also responsible for a limited number of additional 
projects, language-related but not themselves for language 
standards.  The guidelines TRs have already been mentioned.  
The others can be divided into language-independent standards, 
internationalisation, and services and utilities.

The language-independent standards are enabling standards, not 
product standards.  They will not, directly, lead to conforming 
implementations.  Rather, they provide an infrastructure, able 
to be used for future projects, which it is difficult to see 
could be provided in any other way than by standards.  They are 
new, and by their very nature will take a considerable time to 
bear fruit.

The internationalisation area is recognised as one of high 
importance.  It is also of immense complexity.  SC22 has 
monitored progress to try to ensure that it remains focussed.  
It is important that this should continue.

The service and utility projects in SC22 are currently in two 
areas:  PCTE and Posix.  PCTE has only recently arrived in SC22 
by fast track, like other SC22 projects is quite complex, and 
hence also will need time before it can fairly be assessed.

The Posix standards are developed in IEEE, so SC22's role is 
primarily one of coordination, and providing comment from an 
international perspective.  In the decade or so that has 
elapsed since this large and complex project was brought into 
SC22, management has been exercised, rather than the IEEE work 
being taken lock stock and barrel.  This is shown by the fact 
that the SC22 Posix projects are organised differently from 
those in IEEE and not all the IEEE projects appear there.  
Again, it is important that scrutiny should continue, in SC22 
as well as, in more technical detail, by WG15.  Confusion, 
disagreement and transfers of ownership in the Posix-related 
world of Unix have until recently rendered assessment of the 
Posix programme premature, but the time is approaching when a 
comprehensive review will be desirable.

______________________end of document SC22 N2245 ______________________