From martin@ocfmail.ocf.llnl.gov Fri Dec 11 04:54:34 1992
Received: from ocfmail.ocf.llnl.gov by dkuug.dk with SMTP id AA12821
  (5.65c8/IDA-1.4.4j for <SC22WG5@dkuug.dk>); Fri, 11 Dec 1992 21:54:35 +0100
Received: by ocfmail.ocf.llnl.gov (4.1/SMI-4.0)
	id AA27335; Fri, 11 Dec 92 12:54:34 PST
Date: Fri, 11 Dec 92 12:54:34 PST
From: martin@ocfmail.ocf.llnl.gov (Jeanne Martin)
Message-Id: <9212112054.AA27335@ocfmail.ocf.llnl.gov>
To: SC22WG5@dkuug.dk
Subject: Optional or Not?
X-Charset: ASCII
X-Char-Esc: 29


To:      WG5
From:    Jeanne Martin, Convenor
Subject: The question of optionality for Varying Length Character Strings

With respect to the ongoing CD ballot on the varying length character string
standard, I have had three separate inquiries regarding its "optionality".
I think we all agree that our original intention was that this standard be a
[pick one: {companion, collateral, auxiliary}] standard to ISO/IEC 1539:1991
and that it be optional.  That concept does not seem to have occurred to the
preparers of our Directives.

Also, the ISO Directives we were operating under prior to 1990 mention
"Addenda" as a near synonym for "Amendments".  The JTC1 Directives we are
operating under now have dropped the term "Addenda" and use only "Amendments".
An amendment is clearly an extension to a standard that is generally
incorporated in the next version of the standard.
______________________________________________________________________________
Here is a copy of our original request to SC22:
______________________________________________________________________________

               ISO/IEC JTC1/SC22 Working Group 5
               Proposed Project Subdivision for a

                Fortran Varying Character Module



Discussion

There have been numerous requests to add a varying character
capability to the draft proposed Fortran standard.  At its
meeting in Paris in 1988, WG5 determined that this need could
best be met by a standard module as an addendum to the
forthcoming standard revision rather than by adding a varying
character feature to the language.  The following resolution was
passed:

      P7 - Varying Character Module
      
      That WG5 requests the German member body to prepare
      a proposal for a Fortran module for varying
      character and the WG5 Convenor subsequently to
      request SC22 to split the work item to allow
      standardization of the module.

At the 1989 WG5 meeting in Ispra, a delegate from the German
member body presented a prototype of such a module.  He also
requested a minor change in the draft revision which could be
made following the SC22 ballot on the second draft.  The
prototype (See WG5-N418 attached) adequately demonstrated the
feasibility of such a module, and the following resolution was
adopted at the Ispra meeting:

      I9 - Varying Character Module
      
      That WG5 requests SC22 to subdivide Project
      JTC1.22.02 Fortran into
      
      JTC1.22.02.1  Revision of ISO1539
      JTC1.22.02.2  Varying Character Module
      
      As a first draft for Project JTC1.22.02.2, WG5-N418
      can be used.
      
In adition to providing a standard interface for a varying
character capability, this module would serve as an example to
others of the use of the new language extension mechanisms
defined in the current draft proposed revision of DP1539.  WG5
wishes such a module to be standardized as an addendum to the
forthcoming revision of DP1539.


Proposed Resolutions

      Resolution 1  ISO/IEC JTC1/SC22 subdivides its work
      item JTC1.22.02 as follows to provide a Fortran
      varying character module as an addendum to the
      revision of ISO1539:
      
           JTC1.22.02.1  Revision of ISO1539
           JTC1.22.02.2  Varying Character Module
      
      Resolution 2  ISO/IEC JTC1/SC22 requests that the
      German member body provide working drafts of an
      addendum to the revision of ISO1539 for a varying
      character module.
      
      






______________________________________________________________________________
Here is the SC22 Resolution adopted at the Berlin SC22 Meeting, Sept. 26-29,
1989 (WG5-N442)
______________________________________________________________________________

Resolution 132: Subdivision of work item JTC1.22.02 - Fortran

ISO/IEC JTC1/SC22

    - authorizes the subdivision of work item JTC1.22.02 - Fortran as follows:

      JTC1.22.02.01 - Revision of ISO 1539 - Fortran; and
      JTC1.22.02.02 - Variable length character string module;

    - notes that SC22 documents relevant to JTC1.22.02.02 are N680 and N723;
      and

    - requests the German Federal Republic member body to provide a project
      editor for JTC1.22.02.02.

______________________________________________________________________________

At this point I can think of three possible directions we could take to
achieve our original objective:

1. Retain our current approach, but put the word "optional" on the title
   page and put something like the following in the Introduction -

   "This standard is optional.  A processor conforming to ISO/IEC 1539:1991
   is not required to provide facilities for the manipulation of character
   strings of dynamically variable length, but if it does, it should provide
   them in a manner that conforms to this standard."
   
   This is made explicit in the Scope (more than once) but, in my opinion,
   that is not early or obvious enough.  All instances of the term "collateral"
   should be excised.  This term does not have a definition in the Directives.
   JTC1 does not have procedures for optional standards and is unlikely to
   devise any for our needs alone.  By taking this approach we would be using
   the existing procedures, but making them work to our ends.

2. Recast the draft as a Technical Report - Type 3 instead of a standard.

3. Recast the draft as a binding to a varying length character string facility.
   A drawback with this approach is that to have a binding, there may have to
   be an existing language independent standard to bind to.

The direction we choose to take will be discussed and settled at our next
meeting in Germany.  A member body ballot may, of course, indicate a
preferred approach, but the main purpose of the ballot is to flush out
technical issues such as: Are the right facilities provided?  Is I/O
handled correctly?  Are the names of the module and data type appropriate?
