Subject: SC22 N2759 - Comments Disposition on PDTR 14369 Registration - LISS

From: "william c. rinehuls" <[email-masked]>
Date: Tue, 7 Jul 1998 16:43:59 -0400 (EDT)

________________________ 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:  [email-masked]

___________ 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 ___________________________