...
Take into account the the intended audience of the specification is wide. Knowing that product managers, end-users, test developers or product developers not always fully share the author’s background and expertise, be aware that interpretation mistakes or liberties will abound.
In the special case where two or more specifications refer to each other and compose with each other, the specification writer assumes on some aspects, a “black-box” or perfectly modular composition. This implies that some “corner cases” (error escalation, mismatched features) could not explicitly be documented. This way the details are left to the implementers. The degree of variability introduced by such compositions is then underestimated. As a result, implementers may interpret differently how the composition is supposed to operate. This can be avoided by not making any assumptions in case of doubt, and contact the writer of the specification. E.g.: a Vitalink layer will operate above the eHealth Kmehr artefact specification and Hub webservices protocol specification, these are defined outside of Vitalink.
Document the used version of the specification
...
When migrating your implementation to a newer version of the specification, make sure that you have identified and implemented the non-backward compatible features of the specification. This is needed to be able to correctly consume artefacts produced by other applications/implementations using the older version(s) of the specifications.
Processing of optional features
The optional character of a specified feature, when concerning an artifact that may be produced and consumed, is a common source of confusion and interoperability failure. An artifact MAY implement a feature. This clearly means that a compliant device producing such an artifact MAY omit this feature. However, any compliant device consuming such an artifact MUST be able to process this feature, should it be present (unless specified otherwise).
Composition of two specifications
Specifications refer to each other, and compose with each other. For example, a Vitalink layer will operate above the eHealth Kmehr artefact specification and Hub webservices protocol specification, that are defined outside of Vitalink. On some aspects, the specification writer sometimes assumes a “black-box” or perfectly modular composition. This implies that some “corner cases” (error escalation, mismatched features) are not explicitly documented. This way the details are left to the implementers. The degree of variability introduced by such compositions is then underestimated. As a result, implementers may interpret differently how the composition is supposed to operate. This can be avoided by not making any assumptions in case of doubt, and contact the writer of the specification.
Interoperability Testing
The goal of interoperability testing is to prove that end-to-end functionality between two implementations is as required by the specification that is implemented. It ensures end-to-end service provision across two or more products from different vendors.
It is advised to get a thorough understanding of the interoperability testing facilities offered by the writer of the specification. Once this is identified, an own test plan should be defined.In this way useful or important information included in the optional feature, is not omitted for the receiving application.
Interoperability & servicedesk
...