Interoperabolity Events Complementing Conformance Testing Activities
Euclid of Alexandria, the most prominent mathematician of antiquity, is also the leading mathematics teacher of all times due to his treatise on mathematics, ‘The Elements’. When once asked whether there wasn’t an easier way to study geometry than ‘The Elements’, Euclid was said to respond: ‘There is no royal road to geometry’.
Interoperability is what most standards are about. It is the only thing that these standards are about. So is there a royal road to interoperability? Unfortunately, interoperability does not do any better than geometry — there is no royal road to interoperability. Interoperability is extremely difficult to achieve.
Two ways of validating a standard and an implementation are ‘conformance testing’ and ‘interoperability testing’. In conformance testing, manufacturers run their implementation against a set of ‘golden’ test suites; in ‘interoperability testing’, they run their implementations against each other. Frequently, ‘interoperability testing’ is done at ‘bake-offs’, i.e. open events where developers get together to debug a standard and their implementations.
Views on which method is best are at times strongly divergent. Theoretically, if a standard is tight and has only a limited number of options, implementations that pass conformance tests will automatically be interoperable. In practice, however, a ‘pass’ in conformance testing does not necessarily guarantee that two implementations are interoperable. Likewise, if two implementations are interoperable, they may not necessarily conform to the standard. In reality, things probably lie somewhere in the middle, and both conformance testing and interoperability testing pave the road towards interoperability.