From BJSHEP@ausvm6.vnet.ibm.com Wed Feb 17 09:26:25 1993
Received: from vnet.ibm.com by dkuug.dk with SMTP id AA21578
  (5.65c8/IDA-1.4.4j for <sc24@dkuug.dk>); Wed, 17 Feb 1993 22:28:39 +0100
Message-Id: <199302172128.AA21578@dkuug.dk>
Received: from AUSVM6 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 0469;
   Wed, 17 Feb 93 16:26:34 EST
Date: Wed, 17 Feb 93 15:26:25 CST
From: BJSHEP@ausvm6.vnet.ibm.com
To: sc24@dkuug.dk
X-Charset: ASCII
X-Char-Esc: 29

I ENCOURAGE EACH OF YOU TO REVIEW THE DOCUMENT REFERENCED IN THE SUBJECT
LINE BELOW, AND SUBMIT COMMENTS THROUGH YOUR NATIONAL BODIES.  WE NEED
TO DEVELOP A POSITION ON THIS TOPIC AT OUR STEAMBOAT SPRINGS MEETING.



*************************************************************************



TO: Edward J Barkmeyer, Editor of Project JTC1.22.17

FROM: Barry J Shepherd, Chairman of JTC1 SC24

SUBJECT: (2nd) CD 11404 (Language Independent Datatypes)



The following comments are a personal opinion.  I intend to raise this
matter at the next SC24 meeting in July, 1993.  The scope of the LID
and Language Independent Procedure Calling standards is potentially of
great value to SC24 and other SCs.  However, I believe the following
points need to be considered.

1.  SC24 has become used to defining its semantic specifications in terms
    of a rich set of "abstract" data types such as:  2D point, 3D point,
    color specification, etc.  SC24 experts need to determine if the
    "defined datatypes" of the LID CD are an adequate mechanism to map
    their set of abstract data types.

2.  Because much of the content passed by SC24 APIs is in data types
    which are not primitive LID types, the efficiency of mapping defined
    datatypes to specific programming languages of interest will be
    critical to the acceptance of this technology within SC24 and the
    community of users which it serves.

3.  It is not clear that permitted values/ranges can be applied to data
    types outside of the context in which those datatypes are used.  That
    is, there may be times when the range is more sensibly associated
    with the procedure call, rather than the type specification.

4.  It is probably correct that questions of input versus output,
    mandatory versus optional, and specification of initial or default
    values are associated with parameters of procedures, NOT datatypes.

5.  Users of SC24 standards are interested in getting efficient access
    to the functionality in a timely manner.  Thus, we will need to be
    assured that the language independant datatypes, language indepen-
    dent procedure calling, and the mapping of each to programming
    languages of interest to us are all in existence before we leave our
    proven language binding techniques.

I hope that you will continue to keep SC24 informed of the progress of
your work.  Perhaps an expert from your group would be able to provide
us with a presentation during our next meetings in Steamboat Springs
in early July, 1993.


