From BJSHEP@ausvm6.vnet.ibm.com Thu Feb 18 02:36:04 1993 Received: from vnet.ibm.com by dkuug.dk with SMTP id AA23365 (5.65c8/IDA-1.4.4j for ); Thu, 18 Feb 1993 15:40:27 +0100 Message-Id: <199302181440.AA23365@dkuug.dk> Received: from AUSVM6 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 9228; Thu, 18 Feb 93 09:38:28 EST Date: Thu, 18 Feb 93 08:36:04 CST From: BJSHEP@ausvm6.vnet.ibm.com To: sc24@dkuug.dk X-Charset: ASCII X-Char-Esc: 29 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.