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.

For each selected datatype for which ISO/IEC 11404 defines parameters, the language-independent service specification should specify all of the parameter values, either directly, or by placing a requirement to do so upon a conforming implementation of the specification.

The language-independent service specification should specify how a conforming implementation is required to handle data values encountered which are outside the defined set of values for the relevant datatype.

For each datatype, the language-independent service specification should specify the operations on its data values required to be supported, and, where relevant, whether and under what conditions further operations are permitted in a conforming implementation of the specification.

The datatypes used in the language-independent service specification should, as far as practicable, be selected from the following basic set, which are generally supported directly, or able to be simulated without major binding problems, by a wide variety of languages: the primitive datatypes Boolean, Bit, Integer, Character, and the aggregates Array, Record and CharacterString.

With respect to arithmetic datatypes, the language-independent service specification should take into account the provisions of ISO/IEC 10967, Language independent arithmetic, in particular Part 1, Integer and floating point arithmetic.

The language-independent service specification should provide clear guidance on the approach that a language-independent service language binding should take to binding the various datatypes required. Particular care should be taken in the case of complicated abstract datatypes which many languages will have to represent through simpler and less abstract datatypes, and in some cases mandatory requirements may need to be included to ensure that the integrity of the language-independent service is protected.

When defining the datatypes used in the language-independent service specification and the operations to be supported, any explicit or implicit dependence on or assumptions about the form of representation of the datatype values should be avoided as far as possible, the definitions being in terms of abstract properties only. When dependence on some form of representation is unavoidable (e.g. because the language-independent service entails interworking with some other service which does require a particular representation) then the representation requirements should be made explicit, and kept to the minimum necessary for the language-independent service to be performed correctly. The language-independent service specification should also address the issues relating to conversions from and to other forms of representation.

(1) This clause provides guidelines on how to specify procedure calls in language-independent service specifications. Many, (perhaps most) service specifications will find it convenient to define certain actions or functions of the service in terms of procedure calls; indeed, some services may conveniently be defined entirely in terms of procedure calls and the data on which they act. In particular, any required operations on data values (see 12.4) which not all actual languages necessarily provide may well be best defined in that way.

The language-independent service specification should define each procedure call in terms of the overall effect achieved by the call in relation to the service, not in terms of how that overall effect is to be achieved.

The language-independent service specification should, for its procedure calling model, use ISO/IEC 13886 Language independent procedure calling (LIPC).

Care should be taken in the selection of datatypes of parameters, to avoid breaking down complicated datatypes used for definitional purposes into simpler ones for specifying operations, simply because it is known that most languages will not be able to pass as a parameter a value of a complicated datatype. The definition of the procedure should be made at the highest level of abstraction possible (see 13.1) to enable bindings of the language-independent service specification to exploit language features to their best effect.

As far as possible, the language-independent service specification should use the LIPC parameter passing mode "call by value sent on initiation" for each parameter.

The language-independent service specification should require that any implementation of the service or language binding to the language-independent service specification standard conforms in respect of procedure calling to the relevant requirements of the relevant binding to LIPC, where one exists.

In some cases, a language-independent service specification may be best defined in terms of an LIPC-based full service, with a more restricted RPC-based service as a subset. If this is done, it should be ensured that the restricted service is a fully conforming subset of the full service.

(1) Procedure calling is a well-known concept, and exists in some form in all programming languages, or at least all those likely to wish to bind to a language-independent service specification. It is also a simple concept, at least at the level of provision of functionality. However, because procedure calling interacts with other parts of the language concerned, there are many detailed variations between one language and another, not just at the syntactic level, which is relatively easy to deal with, but in terms of the underlying operational model used. Languages vary, sometimes greatly, in their underlying structure and design assumptions, and this can often be reflected in the procedure calling model.

(2) The difficulty for those defining a language binding to an external service is that the service probably will not have exactly the same procedure calling model. There is obvious danger of mismatches, faults, and unexpected behaviour arising because those defining the service made unspoken assumptions about procedure calling while those defining the binding made different unspoken assumptions. This is especially true when those concerned are particularly expert in one language but not very familiar with others.

(3) Hence the first necessity for those defining a language binding is to examine carefully the underlying assumptions of the procedure calling model of the "target" language, and compare these to the underlying assumptions of that used for the service. It is recommended that this be done in each case by first separating the three concepts of defining the procedure; invoking it; and the delivery of its results back to the point of call, and then doing detailed comparison of each of the three.

(4) However, this Technical Report recommends throughout that relating the procedure calling models of the service and the target language by using the common reference point provided by ISO/IEC 13886, Language independent procedure calling (LIPC), which was designed for that purpose. If the language-independent service specification was produced in accordance with the guidelines in this Technical Report, it, and the interface to which the binding will relate, will use the LIPC model, at least as a reference if not for the detail of the specification (see clause 13.2). Even if the service specification is language dependent, a language-independent interface produced in accordance with the guidelines will present the service using the LIPC model - in other words it will act as a buffer between the service's internal assumptions, and the outside world in which those assumptions may not hold.

(5) If the target language already has a defined LIPC binding, in a standard or, failing that, an authoritative document, then those defining the language binding can use that. If not, they will need to define one of their own, covering at least enough to meet the needs of binding to the service concerned. ISO/IEC 13886 has an annex on How to do an LIPC binding for a language which provides guidance for that. Of course, before embarking on this, a search should be made to determine if others in a similar situation have produced partial bindings.

(6) For some services, however, an existing LIPC binding may not be enough, since it will primarily cover invocation and return of results. While this will in many cases be adequate, there may be a need for a common understanding of what happens during execution - for example, when questions of interoperability arise (see clause 10). In such cases, clause ** of ISO/IEC 13886 should be studied, because that provides an abstract formal model of procedure execution for use in such situations.

(1) During the invocation or execution of a service, faults may occur, "fault" being used in a broad sense, to mean any occurrence which prevents, delays or changes the way in which the service would normally operate. For a service to be reliable, it is important to foresee the kinds of fault that may arise, and to determine how they will be handled when they do.

(2) Some faults will be internal to the service itself (i.e. will occur on the service side of the interface). If a fault can be completely handled on the service side so that, with appropriate fault recovery procedures, the service is unaffected, it will not be visible outside, so an language-independent service specification covering only the service interface need not address it. However, if the service is affected, e.g. is stopped, or delayed, or acts in a way other than expected, then the fault, or a manifestation of it, is propagated through the interface, and the language-independent service specification may need to address it.

(3) Some faults will occur at the interface, e.g. arising from a mismatch between what the service user invokes and what the service provider expects. The language-independent service specification will need to address such faults.

(4) Some faults will be specific to the binding. The language-independent service specification may need to address such faults, for example, by identifying them, and saying that they are a matter for the binding.

(5) This clause provides guidelines on how to approach all these aspects of a language-independent service specification.

Requirements should be included covering fault detection, reporting and handling, with appropriate conformity clauses. The language-independent service specification should specify a minimum set of faults which a conforming implementation must detect (in the absence of any masking faults); minimum level of accuracy and readability of fault reports; whether a fault is fatal or non-fatal; and, for non-fatal faults, the minimum recovery action to be taken.

When considering requirements in this area, drafters of language-independent service specifications may well need to take execution overhead into account, which could be considerable for some services, some implementations, or some languages to which the language-independent service specification will be bound. A possible way of dealing with conflicting priorities (e.g. between speed and safety) for differing uses of the service could be to specify that implementation options should be available to allow the level and extent of fault checking to be controlled.

The following is a list of typical faults which can arise in the invocation and execution of a service. Drafters of language-independent service specifications should check all of the following for relevance to their service, and the specification produced should address all that are appropriate, plus others specific to the service concerned. This list is not to be considered either as exhaustive or as prescriptive.

In all cases the language-independent service specification should specify whether the fault concerned is fatal or non-fatal. Depending on the nature of the service, it may occur that a particular fault does not constitute a problem (whereas it would in another service) but that users of the service would nevertheless benefit from the availability of a warning message from the implementation.

Where the specification permits recovery mechanisms from fault conditions, the required results of the actions to be taken by the implementation (when such a recovery mechanism is invoked) should be defined as fully as are defined the normal features of the service.

(1) Options present a special problem for service specifications in general (as indeed for other things), and for language-independent service specifications in particular. Optional aspects of the service, which some implementations have but others do not, can harm interoperability, and can create difficulties for applications using the service, which may need the options and rely on them to be present, or at least need to know (possibly in advance) whether they are there or not. Options in the service interface, or in bindings, can create uncertainties and difficulties, and may damage interoperability of applications using different implementations of the service.

(2) From that point of view, the best course of action is to eliminate options altogether. All implementations, interfaces and bindings will therefore provide the identical service. However, in some environments, providing everything may be technically difficult, prohibitively expensive or actually impossible. A partial service could be offered but it would not conform to the specification and (if the specification is embodied in a standard) users of it would hence not be able to rely on the assurance that conformity to the standard (possibly backed up by testing and certification) would bring. In some environments or for some purposes, providing everything may be indeed be unnecessary; parts would never be used yet the costs of them would remain.

(3) As for implementation dependence, removing it altogether may make implementation impossible on some systems. In contrast, some systems might be able to provide a better level of service (as measured by, say, speed or capacity) than that specified, but would be prevented from doing so. Where characteristics so measured have to be identical, to permit interoperability, this may be unavoidable, but a situation could arise in which implementation, interface, binding and application could all operate at a higher level, without affecting anything outside, but doing so would be precluded.

(4) Services, the way they are used, and the circumstances in which they are used, vary so much that there can be no general rule covering every case. Those responsible for developing the specification, such as a standards committee, will need to weigh all the various factors and make a decision - probably a compromise - accordingly. The guidelines in this clause are aimed at helping them to do that.

Inclusion within the language-independent service specification of optional features of the service, as offered through the interface to users whether as optional additions or as optional alternatives, should be minimized. Ideally, the aim should be to have no optional features at all.

When determining whether to allow a feature of a service to be optional, the fewest assumptions as possible should be made about how or for what purpose the service will be used.

Where complete avoidance of service options is impracticable:

If at all possible, any optional (or higher level) features of the service should be defined functionally in terms of mandatory (or lower level) features.

The service interface specification should allow bindings and user applications access to all the features of the service that are offered externally.

Where the interface is to a service that has optional features, the interface specification should reflect this but still be able to handle invocations of those features by user applications, and provide an appropriate response.

Unless unavoidable, a language binding to the service interface specification should allow user applications access to all the features of the service, whether mandatory or optional, that are available through the interface. If omissions are unavoidable, they and the reasons for them should be fully documented.

Where the language binding is to a service that has optional features, the following possibilities should be considered:

Where the language binding is to a language that has optional features, the binding should make use of the full power of the language, provided

- it does not require syntax additional to that allowed by the standard for the full language;

- an alternative binding, where possible, is provided in cases where the preferred binding uses an optional language facility which is absent from a standard-conforming language processor which omits that option (e.g. a subset language implementation)

- such alternative binding is totally equivalent to preferred binding as far as providing access to the service feature is concerned.

The number of aspects within its scope that the language-independent service specification leaves not completely defined should be minimized (and preferably eliminated altogether). Where full definition is impracticable, in general such aspects should be required to be implementation-defined, subject where appropriate to specified minima or other limits, rather than left as implementation-dependent or undefined. In this case, a complete checklist should be provided of all such implementation-defined features, guidance should be provided for implementors, required limits, as appropriate, should be specified, and the documentation accompanying the implementation should be required to provide for the user a full specification of the implementation definitions used.

The language-independent service specification should specify implementation options required to be provided by a conforming implementation, including in each case a specification of standard default settings of the option and the form or forms in which the implementation options are to be made available to the service interface, bindings, and user applications.

Drafters of language-independent service specifications should consider all of the following features as potential areas for specifying implementation options, and the specification produced should address all that are appropriate for the service and for the kinds of implementation and binding language covered:

- the handling of non-standard features;

- the use of system-dependent or implementation-dependent features;

- the type(s) of optimization;

- the handling of faults and warning messages;

- the handling of overflow and similar range checking;

- operating modes;

- the use of preconnected files and their status on termination;

- the rounding or truncation of arithmetic operations;

- the precision and accuracy of representation and of arithmetic, as appropriate;

- the default settings of service parameter values;

- in the case where the specification is a revision of an earlier specification, the detection and reporting, of usage incompatible with the old specification.

Minimum guaranteed service levels to be supplied by conforming implementations should be specified in appropriate circumstances, namely where:

a) it is probable that user service demands may encounter implementation-defined limits during execution, and

b) such limits can be expressed in terms of the nature of the demand (rather than service implementation issues which may be unpredictable or variable, such as resource capacity);

and provide advice on choice of actual levels.

Examples of features for which it may be appropriate to specify minimal limits in specifications are:

- length of user-supplied or internally-generated character strings handled,

- range of integers,

- internal precision of values of datatype Real,

- magnitude of values of datatype Real,

- number of user files which can be open simultaneously,

- complexity of service requests that can be handled.

When advising implementors on considerations involved in setting the actual values of implementation-defined limits, note that such advice may do one or more of:

- recommending specific values;

- recommending minimum useful values;

- recommending maximum useful values;

- recommending that limits should depend on implementation thresholds where efficiency changes sharply;

- recommending that limits should depend on resource availability, which may fluctuate during execution;

- setting forth other criteria appropriate to the specific service.

In each case the reasons for the recommendations should be explained. Different recommendations may be appropriate for different limits.

It should be noted that appropriate implementation-defined limits need to be made accessible to users, in particular for those performing conformity testing, as well as being documented. Where this is not available through service facilities (such as user "help" facilities), appropriate guidance to implementors should be provided.

(1) 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.

(2) 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.

(3) 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.

(4) 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.

(5) 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.

(6) 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.

(7) Invocation means that the user of the language is able to call upon the service from a program in that language. 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 invoke it. The implementation language for the service is not necessarily the same as the language from which it is called.

(8) Incorporation means that the service is provided by the language. That is, the service is internal to the language - it is included in the language definition. This does not mean that the language is also the implementation language: languages designed for particular applications domains are often implemented in other languages designed for systems implementation.

(9) Both invocation and incorporation require language bindings to the service, which in general will be rather different in style. Furthermore, for a particular service and language, invocation and incorporation will not necessarily 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).

(10) Conformity rules need to cover all these three cases, and in general will be different. Those covering implementation conformity will be the ones which most depend on the nature of the service. The guidelines for specifying conformity of implementations (see 16.1) 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 16.2) 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 specification to be subverted by undue assumptions in the conformity rules.

The conformity requirements on implementations should not make assumptions about the style or mode of provision of facilities of the implementation language.

The conformity of implementations should not depend on representational requirements, or requirements that make representational assumptions.

The conformity requirements on implementations should not assume or require an explicit implementation model.

The conformity clauses for implementations of the service should make very clear that is the end result that matters, not how it is achieved.

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 service does not.

The conformity rules for the service should include requirements on the conformity rules that language bindings apply to their implementations, in order to propagate requirements of the interface to conforming bindings and ensure an adequate level of consistency between bindings for different languages.

The conformity rules of a language-independent service specification should require that any conforming language binding shall adhere strictly to the defined semantics of the service.

Guidelines on the development of language bindings may be found in ISO/IEC TR 10182, Guidelines for language bindings. The following additional guidelines are recommended for use when binding to a language-independent interface specification.

Language bindings to a language-independent service specification should make maximum use of existing bindings for the language to the language-independent standards ISO/IEC 11404, Language independent datatypes (LID) and ISO/IEC 13886, Language independent procedure calling (LIPC).

A language binding to a language-independent service specification should adhere strictly to the defined semantics of the service, even when the conformity rules for the service specification do not make such a requirement.

A language binding to a language-independent interface specification should be designed to include the following parts (though it should not necessarily confined to only to the parts listed).

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

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

7) An annex providing guidance to users of the binding on questions relating to the validation of conformity, and any specific requirements relating to validation contained in (1) and (2) above.

8) In the case where the binding 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.

9) An annex which forms a tutorial commentary containing examples that illustrate the use of the service from within the language.

NOTES

(1) The revision of any specification can create problems for users accustomed to the previous version, and always needs to be carried out with care. In the case of a language-independent service specification, a revision might occur of the service specification, of the interface specification, of a language binding, or of the language of a language binding.

(2) Only a revision of a language binding can be done without, in principle, potentially affecting the others. Revision of a language may imply revision of the corresponding language binding. Revision of the interface specification may imply revision of some if not all language bindings. Revision of the service specification may imply revision of the interface specification and hence to language bindings.

(3) The guidelines in this clause are intended to assist in the planning of revisions in each of these categories.

In this clause, "feature" is used neutrally, to denote any aspect of the specification which is visible to the service user, and/or service implementor.

A new feature is added to the specification without affecting existing features.

A change is made to the specification of a feature which is defined reasonably precisely in the previous version. The feature remains available, but has changed in some way.

A feature which was well-defined in the previous version is rendered invalid by the new specification.

A feature which was not well-defined in the previous version is rendered invalid by the new specification.

A feature which was not well-defined in the previous version, so that its interpretation was open to question, is properly defined in the new specification.

A feature designated in the previous version as obsolescent is deleted or changed in the new specification.

A level of service previously defined in the specification (whether service, interface, or binding) is altered in the new version.

A specified limit (maximum or minimum) in the previous version, for a value left implementation-defined by the specification, is changed in the new version.

For each proposed addition, deletion or modification that represents a potential incompatibility from an earlier version of the specification:

Before any revision of the service specification is undertaken, potential changes should be reviewed and the consequent effect on the interface and on the dependent language bindings should be determined.

Any changes resulting from a revision of the service specification should be specified in such a way as to minimise the difficulty of revising the specifications of the interface and of the dependent language bindings.

Because of possible effects on interface and dependent bindings, the revision of a service specification should if possible be carried out in small steps, correcting, incrementing or modifying a part of the specification at a time, to allow similar correcting, incrementing or modifying of the dependent specifications.

If possible, a revision of the service should be specified in order to absorb the changes, to ensure that unrevised language bindings will still work.

Where the revision of the service takes the form of additional features, an incremental amendment for language bindings should be specified, to allow the new features to be accessible to applications.

When a language binding is revised in response to a revision of the service interface, it should as far as possible shield application programs dependent on the service from any changes to the interface.

When a language binding is revised in response to a revision of the language specification, relevant new language features should be exploited to allow new or revised application programs full advantage of those new features.

18.6.2 Guideline: Buffering "legacy" application programs from changes

Where application programs not yet revised are expected to continue in use, the revised language binding should where necessary make use of the "backward compatibility" provisions of the language revision to allow old "legacy" programs to continue to work.

If necessary, the revised language binding should specify a user option to allow application programs to continue using the old form of invocation, even if the language revision itself makes no provision for legacy programs.

ISO/IEC 10967-1, Language independent arithmetic Part 1, Integer and floating point arithmetic, hereafter "the LIA-1 standard", provides rigorous definitions of the basic arithmetic operations on integer and floating point values. It is at a higher level of abstraction than IEC 559:1989 (IEEE 754:1985) Standard for binary floating-point arithmetic, which specifies an abstract representational and implementation model; though for mathematical reasons it adopts a floating-point notation for definitions relating to "real" (i.e. approximate) values, it does not require or assume that a floating-point representation will be used in implementations. The relationship with IEC 559 is clearly described, for convenience of use with systems that make use of that implementation model. IEC 559 systems can conform to the LIA-1 standard, and many do, but the IEC 559 requirements are less rigorous, primarily because of the presence of options, so IEC 559 conformity does not guarantee LIA-1 conformity.

Further Parts of ISO/IEC 10967 Language independent arithmetic will cover Elementary numerical functions (Part 2) and Complex arithmetic and procedures (Part 3).

The purpose of ISO/IEC 11404:1996, Language independent datatypes, hereafter "the LID standard", is to define a set of datatypes suitable for use as "common ground" between a wide variety of programming languages, and other things which use the concept of "datatype" explicitly or implicitly. The set defined is very rich, far wider than is usual in programming languages, to accommodate the needs of many very different languages and allow them to find LID datatypes corresponding to their own datatypes with the minimum distortion. For the similar reasons, operations on the values are "characterizing", i.e. typical of the datatype concerned, but are not normative, since which operations are provided in a given context, and which are not, are very much dependent on the envisaged field of applications. Again, in almost all cases the datatypes are "purely computational", i.e. concerned with pure values, without any particular semantic or applicational connotations, and capable of use in a wide variety of application fields. In this, LID follows the mainstream tradition of general-purpose languages, as can be seen from the choice of primitive datatypes, though provision is made for the construction of further datatypes which, if necessary, could be application-oriented.

The LID standard follows the common practice of starting with a number of primitive datatypes and then using these to construct others. There are three main kinds of constructed datatypes: subtypes, generated datatypes, and aggregates. (In fact aggregates are technically also generated datatypes, but important enough to deserve separate classification.)

Primitive datatypes are datatypes whose values are regarded fundamental - not subject to any reduction. Many primitive LID datatypes are also generic, in the sense that they have an unlimited number of values, and hence the datatypes often used in practice are confined to a finite subset of them. The reason that they are used, rather than "actual" achievable datatypes, is threefold: it is a convenient way to identify a class of datatypes which is infinite in extent; language definitions commonly use them, thus simplifying the binding between the LID datatypes and the ones used by specific languages; and it allows for the possibility of actually supporting them if a language is designed to do so.

The LID primitive datatypes are Boolean, State, Enumerated, Character, Ordinal, Date-and-time, Integer, Rational, Scaled, Real, Complex and Void - a much longer list than most languages support, for the reasons stated above. Note that Date-and-time is the only one with particular semantic connotations; the exception was made partly because time is so universal a concept, and partly because some mainstream general-purpose languages include it.

Subtypes are created by modifying the value-space of a "base" datatype in various ways - specifying a range or size; selecting values; excluding values; extending the value-space; or defining explicitly how the value-space is constructed from that of a "base" datatype. Any combination of these is possible too. This carries the implication that a subtype may have a wider value space than its base datatype; however, any datatype can be used as the base, not just the primitive ones, and in that context extension is a useful subtype constructor, e.g. you can make a new subtype by extending an existing one.

The (non-aggregate) generated datatypes in the LID standard are Pointer, Procedure, and Choice datatypes, produced from other datatypes by the methods familiar from languages that include them.

The main kinds of aggregate in the LID standard are Bag, Set, Record, Sequence, Array, and Table. Bag is the most general form of aggregate datatype, capable of containing anything; additional properties or constraints are then used to identify various kinds of aggregate datatype that are encountered computationally. These properties and constraints are not all mutually orthogonal; they may interact with others, in various ways. The particular mix of properties used for a given aggregate datatype will depend on the envisaged computational uses of the datatype and its values. The LID standard provides a way of constructing aggregates as needed, by appropriate mixing and matching of a relatively small number of properties. These include homogeneity, size, and the ability for components to be extracted by tagging, keying or indexing. Multidimensionality is of course allowed for.

Finally, the LID standard allows for new datatypes to be produced from existing ones (copies, or "clones") and for further datatypes and datatype generators to be derived from the basic primitive and generated ones - Tree, CharacterString and BitString are examples. Non-aggregate derived datatypes include Bit, Modulo, and TimeInterval.

A.3 Language-independent procedure calling

(1) ISO/IEC 13886 Language independent procedure calling (LIPC) defines a language-independent model of procedure calling of sufficient abstraction to allow the procedure calling facilities of many languages to communicate. An LIPC parameter may be of any datatype definable via ISO/IEC 11404:1996, Language independent datatypes (LID). No distinction is made between "function" procedures that return a value through the procedure name (and hence can be called to provide values to expressions directly), and "subroutine" procedures that do not return a value in such a way. If the language allows for "function" procedures, the language binding maps the return through the procedure name of the evaluated value of the function into an additional parameter of the corresponding LIPC invocation.

(2) A language processor offering LIPC server facilities for a procedure maps the LIPC procedure call definition, including the number and datatypes of formal parameters, into the form of the corresponding procedure call in the language on its side, using the LIPC binding for that language. A language processor offering LIPC client facilities can then invoke that procedure, in terms of the language on that side. The actual parameters are converted by the LIPC client facilities from the local datatypes to the LID datatypes required for the formal parameters, using the LID binding for the language; this process is termed marshalling.

(3) Transmission of the procedure invocation and parameters to the service provider side is outside the scope of LIPC. Once received by the service provider side, the LIPC server facilities unmarshal the marshalled actual parameters from the LID datatypes into the local datatypes used by service provider mapping of the LIPC procedure call definition. Return of results is performed by a reverse process of marshalling on the service provider side and unmarshalling on the service client side.

(4) LIPC specifies four abstract modes of parameter passing: call by value sent on initiation; call by value sent on request; call by value returned on termination; and call by value returned when available. In combination with the datatyping facilities in LID, these four modes cover all of the logical possibilities that binding standards or those implementing standards-conforming language services are likely to need. The standard explains how the common forms of parameter passing found in languages can be expressed with them.

(5) The standard also provides an abstract model of the execution of a procedure call. There is no normative requirement for this execution model to be implemented; it is included as a guide for those defining and implementing LIPC services, to aid understanding and reduce the risk of incompatibilities between language bindings and implementations of client-side and server-side facilities in language processors.

This glossary is derived from the terminology used in the language-independent standards described in Annex A, together with other standards of importance to language-independent specifications, for example those relating to character sets and coding. The definitions are interleaved to assist comparison; sources are indicated as described in clause A.1. For convenience of comparison, the definitions from clause 4, already used elsewhere in this Technical Report, are repeated.

For consistency of presentation, minor editorial changes have been made to the original formats, but otherwise the definitions appear as published. No omissions have been made, even when the definitions appear to be remote from the concerns of this Technical Report; this is to avoid possible misunderstanding, and to assist potential users who may be unsure whether the referenced document is relevant to a project. The only omissions have been the explanations of abbreviations that are included with definitions of terms in the same clause of TR 10182:1993, Guidelines for language bindings.

Where Notes are appended, they are marked as either original, i.e. appearing in the document referenced, or additional, i.e. added for the purposes of this Technical Report. The two kinds of Note are kept separate.

alien syntax (GLB)

A model of a variable or container that holds a value of a particular type.

datatype (LISS)

embedded alien syntax (GLB)

execution sequence (LIPC)

functional specification (GLB)

implementation (of this standard) (LIA)

interface (LISS)

language (LISS)

language binding (LISS)

language binding of F to L or

language-dependent (LISS)

language-independent (LISS)

language processor (LISS)

procedural binding (GLB)

(system facility standard procedural interface)

procedural interface definition language (GLB)

procedure (LISS)

programming language extensions with native syntax or native syntax binding (GLB)

service (LISS)

service provider (LISS)

service user (LISS)

specification language (LISS)