ISO/IEC JTC1/SC22/WG11

Version 3.1, April 1997

Editor's foreword to current version, with issue list 3

1. Introduction 6

2. Scope 8

3. References 8

4. Definitions 9

5. Overview 12

6. Guidelines on strategy 17

7. Guidelines on document organisation 26

8. Guidelines on terminology 29

9. Guidelines on use of formal specification languages 31

10. Guidelines on interoperability 34

11. Guidelines on concurrency issues 38

12. Guidelines on the selection and specification of datatypes 41

13. Guidelines on specification of procedure calls 45

14. Guidelines on specification of fault handling 51

15. Guidelines on options and implementation dependence 53

16. Guidelines on conformity requirements 58

17. Guidelines on bindings 61

18. Guidelines on revisions 64

Annex A Brief guide to language-independent standards 69

Annex B Glossary of language-independent terms 72

[BLM: not for inclusion in final document - BLM]

Change bars since version 2.5 have been added for paragraphs where there have been significant changes, and changed or new wording has been underlined. (It has not been done for the new annexes - nor, for obvious reasons, for this foreword!) It has been done manually since the number of minor corrections has been so great that they would have swamped the significant changes had the automatic facility been used.

In this version two annexes have been added, as decided at the 1996 WG11 meeting: a brief guide to language-independent standards in Annex A and a glossary of language-independent terms in Annex B. There are many detailed changes elsewhere consequent on WG11's review at the 1996 meeting, especially in clauses 1, 5, 6 and 7.

These new clauses 16 and 18, and the two annexes, are so far empty. The other clauses still not yet "complete" are 4 and parts of 13, especially 13.4. Clause 4 still requires WG11 to approve the terminology to be used and to agree definitions. Clause 13.4 requires expertise in RPC that the acting project editor does not possess, and no draft has yet been offered.

The following clauses have not changed other than in some case for correction of typographical errors and minor editorial improvements of wording: 12, 14, 15, 16, 18.

The actions placed upon me at the 1996 meeting of WG11 were:

Action taken: Done, though there may still be still echoes of that terminology in some paragraphs. It is assumed that any such echoes will be picked up during the next review, if they cause confusion, though I hope that "internal" and "external" are now clear enough in their everyday sense from the context.

Action taken: Done, though others will need to check that I haven't slipped up anywhere.

Action taken: Done.

Action taken: Done. I have reviewed it, made note of relevant points, and have gone through them. I think they are now all covered, directly or indirectly - most were already. The main resulting changes have been considerable improvements to Clause 9.

5. Use hyphenation as follows: include it in forms like "this is a language-independent specification" but not in forms like "this specification is language independent".

Action taken: Done, though others will need to check that I haven't slipped up anywhere. (Change indications have not been made for any alterations here.)

Status: Unimplemented

Comments: Yes there should. Make new clause on conformity testing after 16 but also make new clause after 15 on enquiry functions, so that testing validity of the service and its interface can be distinguished from testing availability of the service. That on conformity testing should distinguish between general issues on service and interface and testing for language independence.

Actions: WG11 members and LISS reviewers were requested to submit material to project editor, in the form of proposed guidelines, or identification of existing material which could be used.

Resulting changes: None - insufficient material to use was received.

Acting project editor's recommendation: Omit from the first edition, unless complete usable clauses are received as a result of PDTR balloting. SC22's remit to WG11 was to produce a usable TR as quickly as practicable, even if it was not comprehensive in coverage.

Status: Resolved

Comments: Yes, either in the Foreword (to be added) or in a bibliography.

Actions: The acting project editor was asked to consider how best to do this. In fact it did not seem to me that there was any benefit in having a Foreword additional both to the usual ISO Foreword and the Introduction, or in having a bibliography. Hence I decided to put the reference in the Introduction.

Resulting changes: A new paragraph has been added and the Introduction divided into two subclauses, 1.1 Background, in which the paragraph appears, and 1.2 Principles.

Status: Unimplemented

Comments: (none)

Actions: WG11 members and LISS reviewers were requested to comment on this issue.

Resulting changes: None - insufficient material to use was received.

Acting project editor's recommendation: Omit from the first edition, unless complete usable clauses are received as a result of PDTR balloting. SC22's remit to WG11 was to produce a usable TR as quickly as practicable, even if it was not comprehensive in coverage.

Status: Unimplemented

Comments: Yes, but try to ensure that they do not imply too restricted applicability.

Actions: WG11 members and LISS reviewers requested to submit examples to project editor, bearing the comment in mind.

Resulting changes: None - insufficient material to use was received.

Acting project editor's recommendation: Include suitable examples if any are submitted as a result of PDTR balloting.

Status: unresolved

Comments: Current draft unsatisfactory.

Actions: WG11 members and LISS reviewers were requested to submit material to project editor, in the form of proposed guidelines, or identification of existing material which could be used.

Resulting changes: None - insufficient guidance on required changes was received.

Acting project editor's recommendation: Await comments submitted as a result of PDTR balloting.

Status: unresolved

Comments: Current draft unsatisfactory.

Actions: WG11 members and LISS reviewers were requested to submit material to project editor, in the form of proposed guidelines, or identification of existing material which could be used.

Resulting changes: none as yet.

Resulting changes: None - insufficient guidance on required changes was received.

Acting project editor's recommendation: Await comments submitted as a result of PDTR balloting.

Status: Unimplemented

Comments: (none)

Actions: WG11 members and LISS reviewers were requested to submit material to project editor, in the form of proposed guidelines, or identification of existing material which could be used.

Resulting changes: None - no proposed guidelines were received.

Acting project editor's recommendation: Omit from the first edition, unless usable guidelines are received as a result of PDTR balloting. SC22's remit to WG11 was to produce a usable TR as quickly as practicable, even if it was not comprehensive in coverage.

Brian Meek, 7 April 1997

[Address: Computing Centre, King's College London, Strand, London WC2R 2LS, UK. Please for preference use electronic mail to brian.meek@kcl.ac.uk for comment, or failing that fax to +44-171-836-1799, marked clearly for my attention. Please do not use telephone: I am often hard to reach, and I am unable to return international telephone calls.]

(1) This Technical Report provides guidance to those writing specifications of services, and of interfaces to services, in a language-independent way, in particular as standards. It can be regarded as complementary to ISO/IEC TR 10182 Guidelines for language bindings, which provides guidance to those performing language bindings for such services and their interfaces.

(1) Service or interface specifications that are independent of any particular language, particularly when embodied in recognised standards, are increasingly seen as an important factor in promoting interoperation and substitution of system components, and reducing dependence on and consequent limitations due to particular language platforms.

(2) Potential benefits from language-independent service or interface specifications include:

(1) This Technical Report provides guidelines to those concerned with developing specifications of information technology services and their interfaces intended for use by clients of the services, in particular by external applications that do not necessarily all share the environment and assumptions of one particular programming language. The guidelines do not directly or fully cover all aspects of service or interface specifications, but they do cover those aspects required to achieve language independence, i.e. required to make a specification neutral with respect to the language environment from which the service is invoked. The guidelines are primarily concerned with the interface between the service and the external applications making use of the service, including the special case where the service itself is already specified in a language-dependent way but needs to be invoked from environments of other languages. Language bindings, already addressed by another Technical Report, ISO/IEC TR 10182 Guidelines for language bindings, are dealt with by providing advice on how to use the two Technical Reports together.

(2) This Technical Report provides technical guidelines, rather than organizational or administrative guidelines for the management of the development process, though in some cases the technical guidelines may have organizational or administrative implications.

ISO/IEC TR 10034:1990, Guidelines for the preparation of conformity rules in programming language standards

ISO/IEC TR 10176:1991, Guidelines for the preparation of programming language standards

ISO/IEC TR 10182:1993, Guidelines for language bindings

ISO/IEC 10967, Language independent arithmetic

ISO/IEC 11404:1996, Language independent datatypes

ISO/IEC 11578:1995, Remote procedure call

ISO/IEC 13719:1995, Portable common tools environment

ISO/IEC 13886:1996, Language independent procedure calling

client see service user

formal language, formal specification language see specification language

server see service provider

(1) The concept of a "service" is a very general one. In some contexts it is customary to use it in a restricted sense, e.g. when talking about "service industries" as contrasted with "manufacturing industries". Despite such usages, almost any activity or behaviour can be regarded as a "service", if it serves some useful purpose to do so (for example, manufacturing spoons can be regarded as a service for those needing spoons).

(2) With the concept of a service come the concepts of a "service provider" and a "service user". The provider performs the activity that constitutes the service; the user is the customer or the client for the service, for whom the service is performed. In the information technology field, the "client-server model" incorporates these concepts: the server provides, the client uses.

(2a) Between the service provider and the service user is an interface which allows them to communicate. The service user communicates through the interface the requirement for the service, and any relevant information (e.g. not only the need for spoons, but the number and size of spoons required), and the service provider communicates through the interface the response to the order for the service, and any addition information or queries (e.g. the spoons can be delivered in six days, do you want silver spoons or plastic spoons?). In the information technology field, such interfaces are usually explicit, realised in hardware or software or both. In the world in general, they are sometimes explicit, but sometimes subsumed in more general human or other interactions.

(3) This distinction between provider and user, client and server, must not be assumed to correspond to identifiable distinct entities. The distinction, and the service interface, may be purely notional, and possibly not normally thought of in that way. The service itself may similarly not correspond to a distinct, separate activity, and again and possibly not normally thought of as such; it may be subsumed in some other activity or group of activities, and may possibly be implicit.

(4) Hence, for example, in a transaction between two parties, each one may be providing a service for the other: each is a client, and each a server. In another context, the provider is providing the service to itself; the provider is also the user. Though it may be possible to subdivide the provider/user into a provider part and a user part when considering provision of the service, this may be inconvenient in other respects.

(5) In summary, "client" and "server", are roles that are carried out, rather than elements that necessarily must be implemented separately. Though the term "client-server" is sometimes used in the information technology field in ways that are more specific than it is used here, it is important not to carry over assumptions from particular client-server models when reading this Technical Report. Still more important is not to assume that implementation of any service, in the sense used here, has to be done using a client-server model.

(1) The history of information technology has many instances of the technology, or a product, being used for very different purposes and in very different ways from those originally envisaged. The kinds of service that information technology and products provide have continually expanded and diversified, and this is still continuing.

(2) It is as common in information technology as in the outside world for the term "service" in particular contexts to be used in a rather specific way. The history of the technology suggests that, for the purposes of formulating guidelines about services, the term should instead be used as generally as possible.

(3) This Technical Report has adopted this very general approach to the concept of "service". It is therefore important that, when using this Technical Report and the guidelines it contains, no presuppositions should be made about what a service is, or about how and by what it is provided or how and by what it is used. The guidelines should be interpreted and applied in that light.

(4) Services in the most general sense often simply evolve naturally, but information technology services are usually consciously designed. They are also often built from explicit specifications, though some are developed ad hoc. Whichever the case, it is useful to make a clear logical distinction between service providers, service users, and the interface between them, even if, when implemented, one or both of these distinctions will be purely notional, and will not be embodied in identifiable and separable artefacts like particular hardware components or particular blocks of code. Indeed, thinking about service provision in such a way, in an environment which is normally regarded as a more integrated whole, can help to improve a specification, or at least to test it and verify its validity.

(5) This is especially so in the increasing number of cases where information technology environments and services, though originally conceived as self-contained, have to interact with external environments and services, many of which will need the distinction between providers and users to be made explicit. An instance of direct relevance to this Technical Report is where interacting entities are based upon different languages and hence different sets of underlying assumptions.

(1) The term "language-independent service (or interface) specification" means, in this Technical Report, "language-independent specification of a service (or interface)", not "specification of a language-independent service (or interface)". Hence a language-independent specification of a service does not imply that the service itself is "language independent" in the sense intended here. The service specified may be relevant only to environments of particular languages.

(1a) Also, a language-independent specification of an interface does not imply that the service interfaced to is either itself "language independent", or specified in a language-independent way (though it may be).

(2) A trivial instance is that of a language processor for a particular language providing a service by executing a program in that language. For one of the long-established languages (like Cobol or Fortran) the interface is the provision of input data and the output of results. The language was designed for particular forms of input and output media, presumed under the control of a human user. However, a language-independent interface specification could define the input and output in such a way that the data can come from, and the results be returned to, some other system, in general using a different language.

(3) In a simple case like that, the user system and the interface are distinct and not closely coupled. The interface can be implemented as a "black box" which acts in the same way that a human interpreter would for two people with different languages conversing: it takes input from the client and translates it into the equivalent input for the service, and takes the output from the service and translates it into the equivalent

(3a) In the more general case the interface might need to be embedded in the client system so that it appears to be integrated in that host environment. That environment may need invoking the service to be expressed in more meaningful terms than just sending data and getting results.

(4) Both the simple and the general case are referred to as "binding" to the interface, though the binding is much tighter in the general case. A "language binding" to the interface binds a particular programming language (not, of course, in general the same one as that used by the server), so that programs written in that language can have access to the service. A good language binding allows language users to use a style of accessing the service which is familiar to them, and will also, of course, accord with official standard for the language.

(5) ISO/IEC TR 10182 Guidelines for language bindings provides guidance to those performing language bindings and writing standards for them. This Technical Report provides complementary guidance to those specifying service interfaces in a language-independent way, and writing standards for them.

(6) A way of looking at language independence that can be useful is that of levels of abstraction. The various elements of programming languages can be regarded as existing at three possible levels of abstraction: abstract, computational, or representational, where the middle, computational level can be divided into two sublevels, linguistic and operational. The linguistic elements are regarded as instantiations at the computational level of the abstract concepts, while the operational level deals with manipulation of the elements, which inevitably looks "downwards" to the realisation of the elements in actual, processible entities at the representational level.

(1) As the preceding discussion has shown, a language-independent specification may be a service specification, specifying the service itself, or be an interface specification, specifying the how the service is accessed by clients. It may of course cover both.

(2) This Technical Report is concerned primarily with specification of the interface to the service, rather than of the service itself. The service may be predefined in a language-dependent way. How a service is specified is likely to depend to some extent on the nature of the service and its application area, so guidelines on specification of the service are definitely outside the scope of this Technical Report. However, where it is wished to produce a language-independent specification of a service, so that it can be implemented in a variety of different languages, then the guidelines presented may be useful, directly or indirectly. For example, they may draw attention to factors that should borne in mind, and it may then be possible to adapt them to the particular circumstances.

(3) This Technical Report therefore provides guidelines applicable in the following cases:

(4) Guidelines are grouped under various headings, dealing with different aspects. As far as possible each group is independent, in the sense that they can be referred to without necessarily working through preceding groups. Any necessary cross-references are provided.

(1) Producing a language-independent specification can present many problems, especially if starting from an existing service which was not originally designed to be language independent - typically, a service designed in and for a particular language environment. If a service is specified in the "wrong" way - it may of course not have been "wrong" in its original context - it can make producing a language-independent interface very difficult. In particular, it may making explicit or (more likely) implicit assumptions about the language that applications using the service will be written in. Languages that are similar in character to the original one may not have many problems, but a language-independent interface specification needs to cater for different styles. This is one of the greatest challenges in developing language-independent specifications, whether for services or for interfaces.

(2) Such problems can still occur even if the service concerned is not an existing service. Since most service developers tend to come from a particular language environment, it is all too easy, even when consciously attempting to produce a language-independent specification, to carry over implicit assumptions from that environment, simply because they are implicit and hence rarely questioned or even realised.

(1) An important class of language-dependent assumptions is that of representational assumptions. Some languages have explicit or implicit models of how language elements are represented at the hardware level, either physically or logically. Simple instances are storage of numerical values or of aggregate datatypes such as indexed arrays or character strings, or numbers of datatype Complex (assumed to be represented by two numbers of datatype Real, for the cartesian real and imaginary parts).

(2) Such models tend to become implicit for those used to that language environment, even when the language definition makes the model explicit. Users of the language get so used to that model that they take it for granted. It is all too easy for such assumptions to get carried over into what is intended to be a language-independent specification.

(3) Representational assumptions are not confined to the hardware level, they can occur at more abstract levels too: for example, a supposedly "language-independent" specification may use an integer datatype for a value which logically is not, or need not be, an integer. The fact that virtually all languages have an integer datatype or its equivalent is not relevant: the original language may have used the integer datatype, because it was the best or only choice, but other languages may have alternatives which the original language did not. A language-independent specification should avoid requirements which constrain how things should be represented, and concentrate upon what should be represented.

(1) Representational assumptions are a specific form of implementation assumption, though not all implementation assumptions are language-dependent. Service designers make implementation assumptions when they take it for granted that a particular implementation approach will be adopted. Here a simple example is assuming that the service will be invoked by a procedure call or, even more specifically, will use procedure calls using a parameter passing mechanism of a particular kind.

(2) Implementors of language-independent service specifications should not be required to adopt a particular implementation approach. Instead, the specification should require only what is needed for the service, or is needed to ensure that different implementations will be mutually consistent or (if interoperability is required) interact with one another correctly.

(1) The discussion in clause 5 above shows that a large number of factors need to be taken into account when producing a language-independent service specification. This clause provides guidance on how to go about the task.

(2) The guidelines that follow are divided into general guidelines (clause 6.1) and more specific ones (the later clauses). Some of the more specific guidelines are in fact similar to one another, appearing in various modified and specific forms under various headings, and could have been made "general" guidelines. The apparent duplication increases the length of the document, but is intended to reduce the amount of interpretation and adaptation that will be needed in particular circumstances, and to emphasise the relevance in particular contexts. It also allows different Notes, specific to the context, to be appended.

A service specification should be designed with the requirements for the language-independent interface in mind.

Language-independent service and interface specifications may be affected by issues relating to interoperability with other services, or concurrency, or time constraints of other kinds. If this is the case, the nature of such issues makes it vital that they be addressed first, with the remainder of the service being designed later, around the aspects handling those issues.

When specifying the way that values are communicated across the interface between the application using the language binding and the service, the marshalling/unmarshalling approach used in ISO/IEC 13886:1995 Language independent procedure calling in relation to passing of parameters may prove useful.

When developing a language-independent specification, every attempt should be made to recruit the involvement of, or to obtain input from, language experts from a variety of backgrounds, and also experts in language independence issues. In any event, before the language-independent specification is finalized, arrangements should be made to get a complete draft reviewed by experts of that kind from outside the group designing the specification.

It is rare for the designer of a language-independent service or interface specification to be able to "start from scratch", i.e. to be able to design without having to take into account an existing (and usually language-dependent) service or interface which is already in use (and with which compatibility is required, or expected even if not required.) However, for completeness this Technical Report does need to cover the possibility. Furthermore, guidelines on what ideally might be done can serve as a benchmark against which to measure what has actually been possible, given the constraints that a pre-existing service or interface may have placed upon the design. In principle, they might even establish that it would be preferable to treat the pre-existing version simply as a prototype to be discarded.

When designing a language-independent service specification, representational or other implementation assumptions should be avoided.

When specifying the service in language-independent form, it should not be assumed that implementations in every language will use the same approach, and implementations should not be required to adopt a particular approach. Instead, the specification should require only what is needed for the service, or is needed to ensure that different implementations will be mutually consistent or (if interoperability is required) interact with one another correctly.

If there are external constraints which the service is required to satisfy, these should be carefully examined to assess their impact, whether on implementation strategies for the service, or on the interface. The relevant aspects of the service should then be specified in a way which minimises the impact of the constraints. The external constraints (including the rationale for their presence), and the steps taken in the specification to cope with them, should be documented.

When specifying the service in language-independent form, it should not be assumed that the interface will use or specify a particular binding method; rather, the specification should be neutral with respect to binding methods.

When specifying the interface to the service in language-independent form, it should not be assumed that a particular binding method will be used by every language, and use of a particular binding method should not be required. The specification should require of bindings only what is to be passed across the interface, not how it should be passed.

The task of producing a language-independent service or interface specification from an existing language-dependent specification is one of "reverse engineering". In general it can be expected that the original language-dependent specification will have treated the service, the interface, and the language binding as one, and will not, deliberately, have kept the different aspects separate. For a language-independent specification, whether for a service or for an interface, it is necessary to ensure that these different aspects are kept separate. Clause 6.3.1 provides guidelines on identifying significant language-dependent aspects. Clause 6.3.2 addresses conversion of language-dependent features to language-independent form. Clause 6.3.3 addresses the consequences for language bindings. Clause 6.3.1 addresses the situation where the interface specification but not the service specification is to be made language independent.

Any representational or other implementation assumptions in the original language-dependent specification should be carefully reviewed, and any which are derived from the particular language used, rather than dictated by the semantics of the service, should be identified.

The terminology used in the original language-dependent specification should be carefully reviewed from the language-independent point of view, to see if it is derived from the terminology of the particular language rather than from the service.

The language-dependent specification should be carefully reviewed for features which are specified at a level of abstraction inappropriate for the language-independent version. The review should in particular search for those at too low a level which do not involve overt representational or implementation assumptions as under clause 6.3.1.1, but arise from the way the service has been conceived in the original language environment. Attention should, however, also be paid to any at too high a level, which may take the form of features being left under-specified because the missing aspects are taken for granted in that language environment, or because the language definition leaves such aspects implementation dependent.

6.3.1.4 Guideline: Identifying aspects derived from the language rather than inherent to the service

The language-dependent specification should be carefully reviewed for features which are not inherent to the service, but whose inclusion seems to have been prompted by the nature of the implementation language and its facilities. Particular attention should be paid to any such inessential features which could be difficult to provide in some other languages. Attempts should be made to discover how heavily these features are used by users of the original specification.

The language-dependent specification should be carefully reviewed to see if there are any features which would be desirable, but which are in fact absent from the original (e.g. because they could not conveniently or efficiently be provided in the original language, or where they are implicit in that language and did not need to be spelled out). Any such features should be studied, to see if they should now be added, either as options or as mandatory requirements.

While it is desirable and even necessary to use the original language-dependent specification as a guide when developing a language-independent specification from it, the detailed form and content should not necessarily be dictated by the detailed form and content of the original. In particular, changes that correct weaknesses in the original, and especially changes that enhance language independence, should be seriously considered, and if possible included in the specification, with due regard for the impact on existing implementations using the original specification. However, change should be avoided if what is in the original is adequate for the purpose, and does not adversely impact language independence, even if a change would appear to be an improvement.

In the light of the results of following previous relevant guidelines, the scope of the specification should, if necessary, be recast at as high a level of abstraction as is possible while remaining consistent with the nature of the service.

Language-dependent terms used in the original specification should be changed if necessary, e.g. if they are likely to be misinterpreted in a different language environment. If not changed, they should be clearly explained, for the benefit of those not familiar with the original language or specification.

A suggested strategy for converting a language-dependent specification into language-independent form is to start by converting the datatypes of values used, together with all the required operations on the data, including input-output. If any procedure calling appears in the original specification, conversion of that should then follow. Conversions should be based on what the service needs, rather than what was chosen in the original specification, since those choices are inevitably language-dependent.

The relationship between the original and the language-independent specifications should be fully explained (e.g. in an annex) and all language-dependent assumptions or features that have been recast or removed should be documented. A migration path to allow existing language-dependent implementations to be revised in line with the language-independent version should be provided.

It is possible in some cases that the interface to an existing service (language-independent or not) has not previously been defined explicitly, but exists only in the form of a "binding" to one language, this binding itself probably being implicit rather than explicit. This clause provides guidance on coping with that situation. Mostly, the guidelines below are simply reinterpretations of previous guidelines, adapted to suit those particular circumstances.

Any aspects of the language binding which are derived from the particular language, rather than dictated by the need to interface to the service, should be identified, and replaced by language-independent equivalents where appropriate.

The language binding should be carefully checked, or rechecked, to see if there are any aspects of the service, relevant to the interface, which are in fact absent from it (e.g. because they could not conveniently or efficiently be accessed from the language concerned, or because they were irrelevant for the language).

Any aspects of the language binding which are inessential to providing an interface to the service should be identified, reviewed, and considered for removal from the language-independent interface specification.

The language-independent interface specification should not be based on the assumption that the (explicit or implicit) binding method used for the original language will be used for all other languages.

It is quite possible that the existing service for which a language-independent interface is needed is itself specified in one particular language and is therefore, at least potentially and possibly necessarily, language dependent. This clause provides guidance on coping with that situation. The guidelines below are primarily logical extensions or adaptations to others elsewhere in this Technical Report.

The language-independent interface should be specified in a way that protects language bindings as much as possible from the language dependence of the service, by absorbing the limitations and assumptions arising from the language of the service, and providing the necessary conversions within the interface, rather than propagating them to the bindings.

A language-independent service specification can be a very complex document, depending on the complexity of the service and the scope of the specification. This clause provides guidance on how to organise the material needing to be covered.

The language-independent service specification should be designed to include the parts in the checklist that follows in Clause 7.1.1 (though it should not necessarily confined to only to the parts listed). Where a particular part seems not to be necessary in a given case, allowance should still be made for its possible future inclusion, e.g. as a result of a later change in the scope of the specification, or of a development of the service concerned.

9) An annex containing one or more checklists of any implementation-defined features.

10) An annex containing guidelines for implementors, including short examples where appropriate.

11) An annex providing guidance to users of the language-independent service specification on questions relating to the validation of conformity, and any specific requirements relating to validation contained in (1), (3), (5) and (6) above.

12) In the case where the language-independent service specification is a revision of an earlier version, an annex containing a detailed and precise description of the areas of incompatibility between the old version and the new version.

13) An annex which forms a tutorial commentary containing examples that illustrate the use of the service.

If the scope of the specification includes the semantics both of the service and of the interface, the two should not be intermingled in the document, but kept clearly separate. The same applies to any issues relating to language bindings.

Though guideline 7.1 does not imply that the "parts" of the specification should be in a number of physically separate documents, for a very complex service this should be considered, especially if different aspects (the service, the external service, language bindings, etc) are likely to be implemented separately.

Where a language-independent service specification is being developed which is based on an existing language-specific specification, and changes to the original document organization may seem desirable in the language-independent case, the benefits of such changes should be weighed against the value of maintaining a close correspondence between the two, to aid comparison and review.

The careful and precise use of terminology is important for any kind of specification, particularly a standard specification, but it is especially important for language-independent service specifications.

The terminology used in a language-independent service specification should be defined rigorously, even where it is believed that a term is generally well understood. Different usages of the same terminology (and unspoken assumptions that may not hold) commonly encountered in language communities should be pointed out.

All normative terms and phrases, once defined rigorously in accordance with 8.1 above, should used consistently throughout the language-independent service specification, with the precise meaning as defined.

All uses of undefined terms in the language-independent service specification should be carefully checked to ensure that they cannot lead to normative ambiguity.

As far as possible, the language-independent service specification should use the terminology given in the appropriate parts of ISO 2382, taking into account common practice in the community providing and using service, and in the various language communities concerned, and also the possible costs of transfer to new terminology. ISO 2382 terminology should nevertheless be used in preference to terminology specific to one particular implementation or binding language. Additional terms not covered by ISO 2382 should be defined in a specific section of the standard.

Though definition of terms can be by normative reference rather than detailed exposition, the language-independent service specification should in general include the text of the referenced definitions, at least for information, and it should be made clear that, since usages vary, users of the language-independent service specification should not assume (without having explicitly checked) that their habitual use of a term is identical to that given.

Language bindings should be explicitly required to address and explain fully any differences of terminology between the language and the language-independent service specification.

Serious consideration should be given to the use of a formal specification language to define the service semantics.

(1) Services vary so greatly that it would served no useful purpose for this Technical Report to recommend the use of one formal specification language or even one style of formal specification language. However, to assist those using this Technical Report, there follows a list of formal specification languages which have been made the subject of international standards, together with a brief indication of their style and of their range of applicability.

Care should be taken if using operational semantics for formal definition of a language-independent service specification, to avoid appearing to provide an implementation specification.

The term interoperability is used in many contexts, sometimes in a very vague and general way, and is sometimes confused with the related but distinct concept of portability. This introduction is intended to clarify the concept of interoperability in the context of service specifications, as a preliminary to the associated guidelines for language-independent service specifications.

(1) Interoperability issues arise when a service is required to interoperate with other services in the course of providing its own services to an external user. The other services concerned may be other instantiations of the same service, or may be different services, or of course both.

(2) If interoperability is with other instantiations of the same service, that becomes one of the design requirements of the language-independent service specification and while, this may add to the difficulty of defining the specification, it is a relatively straightforward situation to deal with.

(3) If interoperability is with different services, then the extent of the difficulty of defining the specification will depend upon whether these are being specified at the same time, or pre-existing services that are already specified.

(4) In general, the effect of interoperability requirements is to add constraints to the specification, which is why the strategic guideline 6.1.2 recommends that they be deal with first, along with any concurrency requirements (clause 11), when developing a specification. When constraints arise in connection with other instantiations of the same service, or different services being specified at the same time, though they will exist they may not be especially troublesome. Constraints are likely to be much more severe when interoperability is required with an existing, already specified service, since it is unlikely that it will be possible to alter the specification of that service to make interoperability easier. Even if the specification of that service is being revised, the scope for adjustment to ease interoperability may be limited, or even non-existent.

(5) In the worst cases, the constraints may create pressure to compromise the aims of the language-independent service specification, for example if another service makes representational assumptions about exchange values, or makes other implementation assumptions which have an impact on interoperation. They may even create pressure to compromise the aim of language independence. This needs handling with great care, and preservation of language independence may require some ingenuity. This clause provides some guidelines on dealing with such situations.

(6) Severe constraints can also occur if there is a need for synchronicity, or at least some guaranteed response time. If the service being specified has to meet such a requirement for an external user, the need to interact with some other service can create complications. Alternatively, if the other service demands synchronicity or other forms of time constraint, this can potentially affect the ability of the service to respond to its own external users. In general, how services can handle time constraints is outside the scope of this Technical Report, except that languages vary very greatly in their ability to handle synchronicity and time constraints, which may place severe difficulties in the way of defining the service itself, or language bindings, in a truly language-independent way.

(7) Though the nature of the other services is the most important factor affecting interoperability, two other factors may be important: the nature of the interoperation, and how it is invoked.

(1) Interoperation may be master-slave, slave-master, or peer-peer. In a master-slave relationship, the language-independent service invokes the other service, but has to do no more than state its requirements, expecting the other service to deliver what is required. In a slave-master relationship, the language-independent service is invoked by the other service, and has to deliver what that other service requires. In a peer-peer relationship, the services cooperate to deliver what the external user requires.

(2) The master-slave situation should cause relatively little difficulty, the first because it is a matter only of invoking the other service and being able to handle its various responses. The slave-master situation can be treated as if the other, "master", service is another external user, with its own interface, the main problems arising if the other service is pre-defined and imposes requirements involving severe constraints. The peer-peer situation may also involve severe constraints if the other service is pre-defined, and may pose tricky design problems.

(1) Interoperation may be invoked by the external user (e.g. by exercising an option or selecting a parameter) or may take place in the background, solely within the service, so that the external user is not directly concerned with it (and may not even be aware of it).

(2) Neither of these situations should present too many problems, provided that it is clearly understood which form of interoperation is involved, and it is handled in the appropriate way. Where interoperation is invoked by the external user, this can be treated as part of the interface like any other feature of the service. Where interoperation takes place solely in the background, depending on the nature of the interoperating service it may be appropriate to define an explicit further interface, separate from the interface to the external user, to handle the interactions. Difficulties are likely to occur only when these two situations are confused, or not kept clearly separate.

Where interoperability is required with other instantiations of the same service, it is probable that the relationship will be peer-peer. The guidelines that follow are therefore devised on that assumption. Circumstances can be envisaged in which this is not the case, in which case the guidelines in clause 10.3 for the master-slave relationship will need to be appropriately adapted.

All aspects of the service that affect interoperability with other instantiations of the service should be identified, and the specification should ensure that these are clearly distinguished from other aspects.

All aspects of the service that affect interoperability with other instantiations of the service should be precisely defined, and conformity requirements should be made rigorous enough to ensure that the ability to interoperate will always be maintained, whatever combination of options and implementation-defined choices are used by this and the other instantiations.

In specifying interoperability requirements, particular attention should be paid to the datatypes used for exchange values, and to the exact ranges of validity of data values needed for interaction.

(1) Where interoperability is required with other services, it is possible that the relationship will be peer-peer, but more likely that it will be master-slave or slave-master. A peer-peer relationship is most likely to occur when specifications for the two (or more) services are being developed together. Master-slave or slave-master relationships can occur with specifications being developed together, but it is more likely that the "slave" service will be defined first and the "master" service is specified later to make use of it. However it can happen that a "master" service is defined and then (for example at a revision which extends the service) requires a "slave" service which it can invoke.

(2) The guidelines that follow therefore cover the two main cases, of services (whatever the relationship) being developed together, and of a service being developed to interoperate (whatever the relationship) with some pre-defined service.

Where interoperability is required with other services which are also being defined at the same time, the services should be regarded as a single "super-service" in respect of the interoperability aspects, and the guidelines in Clause 10.2 should then be applied to that "super-service".

Where interoperability is required with another service which is already, all aspects of the pre-defined service that affect interoperability with the service now being defined should be identified, particular note being made of those which impose pre-defined requirements. If these requirements are specified in a language-dependent way, they should be re-specified in language-independent form. An interface should then be defined which allows the language-independent service to appear to the pre-defined service as if it were a service in the same language. All definitions should be made precise, and conformity rules should be made rigorous, especially for this interface, particular attention being paid to exchange values.

(1) Concurrency issues, i.e. issues concerning whether actions should take place serially or in parallel, can arise within the specification of the service, in the way the interface with users of the service operates, or in what the service, through its interface, requires from the user.

(2) In general, the processes of a service can be divided into three groups: essentially serial, optionally concurrent, and essentially concurrent. A process that is essentially serial has to have its parts carried out in a specified sequence if it is to function correctly. A process that is essentially concurrent has to have its parts carried out in parallel if it is to function correctly (though the parallelism can often be simulated by a serial process achieving the same end result, if there are no external constraints to make that impossible). A process that is optionally concurrent will function correctly whether or not its parts are carried out in parallel (since the parts are not interdependent in any way that affects the process).

(3) In this clause, the term "concurrency requirement" is used to denote any requirement relating to any of these three possibilities; in particular it may mean either or both of a requirement to perform tasks in a given sequence or of a requirement to perform tasks in parallel.

(4) In general, the effect of concurrency requirements is to add constraints to the specification, which is why the strategic guideline 6.1.2 recommends that they be deal with first, along with any interoperability requirements (clause 10), when developing a specification.

A language-independent service specification should avoid concurrency requirements other than any which are absolutely necessary to provide the service; in particular it should not require serial processing when parallel processing can achieve the required, nor should it require actual parallel processing (as opposed to simulated parallel processing) unless this is demanded by external constraints or the nature of the service. Every apparently necessary concurrency requirement should be examined closely, to see if there is a way of avoiding it, so that the number that eventually remain in the specification is kept to a minimum.

Depending on the nature of a service, it may necessarily have to deal with one user at a time. In that case it may be possible that it will not be able to accept a demand from another user until the current one has been dealt with, or it may be able to support a queuing system, where incoming calls on the service are accepted as they arise, but are still dealt with one at a time. Alternatively, it may be able to handle a number of service users simultaneously.

A language-independent service specification should explicitly state whether an implementation must be capable of handling concurrent service requests, and if so whether the services must be provided concurrently, or may be queued and the service provided to the users in the queue one at a time.

Where handling of concurrent service requests is required, either through simultaneous provision or by a queuing system, the language-independent service specification should state the minimum number of such requests that it must be possible to handle simultaneously, and require the maximum number that can be handled to be documented.

A language-independent service specification should explicitly state whether an implementation must handle service requests in order of arrival, or may prioritize requests, or must prioritize requests.

Where a service must or may prioritize requests, the language-independent service specification should explicitly define the criteria which must or may govern prioritizing decisions, or at a minimum specify constraints which must be met.

In a language-independent service specification, requirements on users are expressed as requirements on language bindings, through the service interface. This clause provides guidelines for handling concurrency issues that may arise in the specification of such requirements.

A language-independent interface of a service specification should explicitly be neutral with respect to concurrency, i.e. it should place no requirements on whether an implementation of a language binding uses a serial or a parallel approach or any combination of the two.

Where a language-independent interface of a service specification cannot be neutral with respect to concurrency, e.g. through external constraints, the unavoidable concurrency requirements should be specified fully, but in as general a way as possible so as to place the fewest possible constraints on bindings. In particular, no explicit or implicit assumptions should be made about how a language may support parallelism.

(1) Probably without exception, all service specifications will make use of the concept of data, and any specification will need to define the data to which it applies. The commonest and clearest way of doing this is by means of datatypes: a data value which belongs to the relevant defined datatype is covered by the specification, while a data value which does not belong to the relevant defined datatype is not so covered (and in general an attempt to use such an incorrect value will constitute an error).

(2) This clause provides guidelines for the selection and use of datatypes in language-independent service specifications.

The datatypes used in the language-independent service specification should be selected from those defined in ISO/IEC 11404, Language-independent datatypes, either by direct adoption, or using the methods it defines for generating further datatypes from those directly provided in the standard.