From: [email-masked]
Date: Thu, 18 Feb 93 08:36:04 CST

PLEASE REVIEW THE DOCUMENT MENTIONED IN THE SUBJECT LINE AND
   SUBMIT YOUR COMMENTS THROUGH YOUR NATIONAL BODIES.  I BELIEVE
   WE NEED TO ADD THIS SUBJECT TO OUR STEAMBOAT SPRINGS AGENDA.

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

TO: Paul Bartoli, chairman of JTC1 SC21

FROM: Barry J Shepherd, chairman of JTC1 SC24

SUBJECT:  Draft report on NWA for programmatic interfaces
          JTC1 SC21 N7425

The following comments are a personal opinion.  I expect to raise this
subject at the next SC24 meeting, in July 1993.

The first draft report of the SC21 study group on APIs is obviously the
product of a lot of effort.  It appears to address many of the needs of
SC21.  However, it does not seem to recognize either the activities or
environments of other SCs.  In particular, it seems to take the view that
"services" can be defined independent of an application programming (or
programmatic) interface.  I make this claim based on the content of
clause 7.1 and also Annex B of the draft report.

For the work of SC21, I agree that a "service" can be defined without
an API to invoke that service.  That is probably true for any protocol
based activity, which constitutes much of SC21's program of work (based
on the content of Annex B of the draft report).

However, the last sentence on page 13 shows a lack of understanding of
the work of at least SC24, when it states that Annex B lists projects
(in SC24) which COULD lead to "standard progammatic interfaces".  The
projects listed there, as well as other "APIs" such as GKS (published
in 1986) and PHIGS (published in 1990), are themselves the sort of SPI
described in this report.  They specify functionality in a programming
language independent manner directly, without the need of a subsequent
SPI.  We have also produced several language bindings to those APIs,
and industry has provided implementations which are used by large
numbers of applications and users.

I will grant that our APIs are at the "programmatic reference point"
described in clause A.3.   We have avoided specifying conformance at
the perceptual reference point, except in general terms ("That looks
like a red circle to me").  Our CGM standard does address the inter-
change reference point, but it does not have (and probably never will
have) an associated API.

It is not at all clear that SC21 experts have adequately considered
the success of SC24 in developing language independent specifications
and language bindings to those specifications.  It is not at all clear
that SC24 needs to employ the terminology and methodology of the
reference model for Open Distributed Processing in order to continue
to do its work.

It seems to me that mutual education is needed in order to address the
two questions implied in the preceding paragraph.  Could you consider
sending an expert to take part in discussions on this matter at our
next SC24 meeting early in July 1993 in Steamboat Springs?  I hope you
will continue to provide copies of your reports to the SC24 secretariat.