From rinehuls@access.digex.net Tue Jul 7 22:44:18 1998 Received: from access4.digex.net (qlrhmEbBUV1EY@access4.digex.net [205.197.245.195]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id WAA10411 for ; Tue, 7 Jul 1998 22:44:16 +0200 Received: from localhost (rinehuls@localhost) by access4.digex.net (8.8.4/8.8.4) with SMTP id QAA28549 for ; Tue, 7 Jul 1998 16:43:59 -0400 (EDT) Date: Tue, 7 Jul 1998 16:43:59 -0400 (EDT) From: "william c. rinehuls" To: sc22docs@dkuug.dk Subject: SC22 N2759 - Comments Disposition on PDTR 14369 Registration - LISS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ________________________ beginning of title page ______________________ ISO/IEC JTC 1/SC22 Programming languages, their environments and system software interfaces Secretariat: U.S.A. (ANSI) ISO/IEC JTC 1/SC22 N2759 TITLE: Disposition of Comments Report on PDTR Registration for PDTR 14369 - Information technology - Programming languages, their environments and system software interfaces - Guidelines for the Preparation of Language Independent Service Specifications (LISS) DATE ASSIGNED: 1997-07-07 SOURCE: Secretariat, ISO/IEC JTC 1/SC22 BACKWARD POINTER: N/A DOCUMENT TYPE: Disposition of Comments Report PROJECT NUMBER: JTC 1.22.46 STATUS: N/A ACTION IDENTIFIER: FYI DUE DATE: N/A DISTRIBUTION: Text CROSS REFERENCE: SC22 N2755 DISTRIBUTION FORM: Def Address reply to: ISO/IEC JTC 1/SC22 Secretariat William C. Rinehuls 8457 Rushing Creek Court Springfield, VA 22153 USA Telephone: +1 (703) 912-9680 Fax: +1 (703) 912-2973 email: rinehuls@access.digex.net ___________ end of title page; beginning of report _________________ Disposition of Comments received on the PDTR Registration Ballot for PDTR 14369: Guidelines for the preparation of language independent service specifications (LISS), document SC22 N2658. Comments (with a Yes vote) were received from Japan and Denmark. 1. Disposition of Comments from Japan. All comments are accepted with one remark: - the comments relating to ISO 2382: it is not clear exactly which part of ISO 2382 needs to be referenced. The editor will get in contact with the Japanese delegate in WG11 to clarify this point, and to correct this issue in the draft before the DTR ballot. 2. Disposition of comments from the UK. Most comments are accepted, and wording changes are applied. The following comments are not accepted, or need a special response: - 3. Clause 4.3 last para before Note. This could do with re-writing as it doesn't explain what the abstraction levels are. Response: the notions "abstract", "computational" and "representational" are considered to be well-known in the area of programming languages. See for instance the article by Brian Meek titled "Programming Languages: Towards Greater Commonality", ACM Sigplan Notices No 4 (April 1994), also WG11 N330. Should a reference be introduced? - 4. 5.1.2 refers to "time constraints", but there aren't any specific guidelines in this area. Should there be? Response: no; this is not considered an issue for this TR. - 5. 5.2.1.1 typical assumptions (and elsewhere, especially 5.2.3 for binding methods, 5.3.1.2 for terminology) It would be very helpful if some practical examples could be given. Response: accepted in principle. WG11 will consider to produce examples. In the mean time, proposals are welcomed. - 6. 5.3.4.1 needs some expansion and also it's not clear what the differences are to 5.3.2. Response: partly accepted: the text will be improved. 5.3.2 is about converting an existing language-dependent specification, 5.3.4(.1) is about specifying a new LI specification. The difference is subtle, but is considered enough to merit a different approach. - 9. 8.1 Does ASN.1 have any relevance here (perhaps only in reference to service syntax and bindings)? Response: no, ASN.1 is not considered to be relevant here. - 13. 9.2.3 Is there a need to distinguish LI-specific services from non-LI ones, as guaranteed interoperability with LI-specified ones may(?) be more difficult? Response: rejected: it is not clear to exactly which text this comment is referring to. In general, it is assumed that the nature of the specification (LI or non-LI) of a service is independent of the ease by which interoperability with that service is achieved. - 15. 10.2.1 what is the impact here of multiple instantiations of the same service? Response: an implementation issue on `concurrent handling of multiple service requests'. No change is proposed. - 16. 10.3 Some consideration of the serialization impacts of some internal processes as a result of the processing of multiple service requests concurrently may be needed here. Response: rejected; this is considered to be an internal service issue, and not an service specification issue. - 17. 11.3 Note 1 should expand on the implications with regard to subsequent revisions of the specification when disallowed values may now be valid. Response: rejected; this is handled in 17.1.1. - 18. 11.4 discusses "the operations on its data values". Is this really needed, since aren't these just the details of the service specification? Also why do we need to consider "further operations"? Response: this is to ensure a correct mapping between the (newly defined) LI datatypes and the PL datatypes. And on the further operations: suppose a datatype requires a rotate operation? Then that better be specified. - 19. 12. Shouldn't there be a guideline to say that all data which might be shared between caller and callee should be explicitly passed across the interface? Response: no. Suppose a PL has no concept of procedure parameter. Then all data is `global data'. The binding should specify where the parameters can be found in the global space. - 20. 12. Should there be guidelines about naming standards, e.g. uppercase, perhaps other restricted character sets? Response: no: that is a binding issue. - 21. 12.3.2 Note 4 para 2. Isn't this the preferred option and therefore stated as such? Response: this is a binding issue. From the LISS point of view, only the (LIPC) "call by value sent on initiation" is preferred. _______________________ end of SC22 N2759 ___________________________