Statement on formal specifications on ODP Trading function

• The material in ISO/IEC CD 13235-2 Annexes D and G is essential for people working on trader implementations. Therefore, preservation of that material is very important. We suggest that this material is collected to a technical report and published within ISO.

• The material in ISO/IEC CD 13235-2 Annexes D and G captures also relationships between trading function and some other functions, such as type repository function. Therefore, the material should not be hidden within the standard 13235-2, but it should be exploited for component composition standards later on in the work plan.

Statement on "ODP Trading function -- Part 2: Implementation conformance statements and test cases"

1. The scope of the document.

   The process of test case derivation is not an integral part of this standard. We suggest that Annexes D and G are removed from this standard.

2. Types of conformance points.

   The current document identifies the need of defining four types of conformance points: perceptual (changes in real world caused by the software), programmatic (interfaces with other software components), interworking (interaction with such software components that are under foreign administration), and interchange (data portability). However, the text discusses only programmatic test cases.

   In our opinion, the interworking conformance points are the only kind that is relevant for trading function, because

   • programmatic conformance points should be equal (or refine) to interworking conformance points;
   • the standard should claim that perceptual effects are nonexistent; and
   • the standard should claim that there is no interchange requirements.
   In this standard, all relevant reference points can be tested using the methods described for OSI protocol testing.

3. The relationship between viewpoint specifications and implementations.

   A single viewpoint specification does not define a system (a function) from all relevant points. Therefore, conformance can not be tested against a single viewpoint specification. We need to act as defined in ODP-RM Part 3, for example in clause 5.3.:

   "An implementor claiming conformance must identify the engineering reference points which give access to the system and the engineering, computational, and information specifications which apply to them. By this act the identified reference points become conformance points. The interactions at these conformance points can then be interpreted in enterprise language terms to check that the enterprise specification is not violated."

   We need to create a set of tests that check invariants for information, state changes for information in regard to operations. Most of these test are apparently present in the current document. However, the test cases are motivated and organised by individual viewpoint specifications. We suggest, that motivative parts are removed, and viewpoint organisation is collapsed to a organisation along operations and operation combinations.

4. Generation of test cases.

   This standard should indicate classes of test cases. The instances can then be generated for example with automated tools.

5. The scope of conformance testing.

   This standard should only show the test cases for trading function alone. For example, the effect of service types in use should be factored out from the test cases.

6. Organization of testable units.

   Each role in computational viewpoint identifys a commercial product that can be conformance tested on its own. Therefore, tests must be described for importer, exporter, and administrator client-interfaces.

7. Effect of enterprise, information, and computational viewpoints.

   Policies induce an abstract state machine that restrict the behaviour of the implemented object. Oblications indicate what transitions must occur, prohibitions indicate states that may not occur. Permissions can not be directly tested (must be transformed to prohibitions first).