If the specification (of the service, the interface, or a binding) is to be included in a formal standard, then formal conformity rules will be required. This clause provides guidelines on how to do this.
Note - Much of this clause is based on the guidelines in ISO/IEC TR 10034:1990, Guidelines for the preparation of conformity rules in programming language standards.
Even if the specification is not being designed with formal standardization in mind, any document containing it will need to make clear what is required to meet the specification, though it may be felt unnecessary to make the conformity requirements quite so strict as those in a formal standard should be.
The guidelines here are based on the assumption that strict and formal conformity rules are required. If the circumstances are regarded as less demanding, then some relaxation may be possible. However, in general both implementors and users of any service, standardized or not, will be helped by a rigorous definition of what is required, since there cannot then be any doubt.
What kinds of entity will be expected to conform to the specification, and the rules to be laid down for such conformity, will depend greatly upon the nature of the service being specified, and in that respect these guidelines can do no more than indicate general principles. In respect of the language-independent nature of the specifications, the consequent relationship with actual languages, and what this implies for conformity rules, these guidelines can be more specific.
There are three kinds of possible relationship between a programming language and a language-independent service specification, which can be summarized as implementation, invocation, and incorporation.
Implementation means that the language is used to implement the service. At its simplest, the service is provided to the user as an executing program. The user, in general, does not know, and should not need to know, what language the program is written in.
Note - This relationship is relevant for a specification of the service. Though the specification of services in general is outside the scope of this report, specification in respect of language independence is in scope, and is covered in below.
Invocation means that the user of the language is able to call upon the service from a program in that lan-guage. The term reflects the familiar simple case of a user invoking a procedure from a procedure library.
The essence in this case is that the service is logically external to the language, but language users can in-voke it. The implementation language for the service is not necessarily the same as the language from which it is called.
Incorporation means that the service is provided by the language. That is, the service is internal to the lan-guage - it is included in the lanlan-guage definition. This does not mean that the lanlan-guage is also the implementa-tion language: languages designed for particular applicaimplementa-tions domains are often implemented in other lan-guages designed for systems implementation.
Both invocation and incorporation require language bindings to the service, which in general will be rather dif-ferent in style. Furthermore, for a particular service and language, invocation and incorporation will not neces-sarily be totally mutually exclusive. Normally, a language will have only one binding to the service, which will be an invocation-style binding, an incorporation-style binding, or a mixture (since, for a particular service and language, invocation and incorporation will not necessarily be totally mutually exclusive).
Conformity rules need to cover all these three cases, and in general will be different. Those covering imple-mentation conformity will be the ones which most depend on the nature of the service. The guidelines for spe-cifying conformity of implementations (see and Error: Reference source not found) will be confined to general principles and how to avoid making undue assumptions about the nature of the implementation language.
Conformity rules covering invocation and incorporation will be rules for conformity of the language bindings.
The guidelines for specifying conformity of language bindings (see ) will address how to avoid making undue assumptions about the nature of the binding or the language being bound to, and how to make the language bindings as simple as possible. The general guidelines for specifying the service will of course address those questions, but they also need to be addressed here, since it is possible for a good language-independent spe-cification to be subverted by undue assumptions in the conformity rules.
15.1Guidelines for specifying conformity of implementations of the service
15.1.1Guideline: Avoidance of assumptions about the implementation language
The conformity requirements on implementations should not make assumptions about the style or mode of provision of facilities of the implementation language.
15.1.2Guideline: Avoidance of representational assumptions
The conformity of implementations should not depend on representational requirements, or requirements that make representational assumptions.
15.1.3Guideline: Avoidance of implementation model
The conformity requirements on implementations should not assume or require an explicit implementation model.
15.1.4Guideline: Requiring end results rather than methods
The conformity clauses for implementations of the service should make very clear that is the end result that matters, not how it is achieved.
Note - The normative text of the specification needs to be equally clear in this respect.
15.2Guidelines for specifying conformity of implementations of the interface
15.2.1Guideline: Requirements on implementation-defined aspects
Conformity requirements for implementations of the interface should address implementation-defined aspects of the service (e.g. maxima or minima of implementation-defined values), even if the specification of the ser-vice does not.
Note - Such requirements will assist in defining language bindings to the interface, since they help to determine the minimum level of service that a language user can expect from a binding.
15.3Guidelines for specifying conformity of bindings
15.3.1Guideline: Propagating requirements to conforming bindings
The conformity rules for the service should include requirements on the conformity rules that language bind-ings apply to their implementations, in order to propagate requirements of the interface to conforming bindbind-ings and ensure an adequate level of consistency between bindings for different languages.
15.3.2Guideline: Adherence to defined semantics
The conformity rules of a language-independent service specification should require that any conforming
lan-guage binding shall adhere strictly to the defined semantics of the service.
Notes
1. See Note 1 in .
2. Other guidelines in this Technical Report make it clear, however, that conformity rules should avoid imposing on bindings inflexible requirements that are inessential to the correct functioning of the service.