...
Take into account that 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 In the special case where two or more specifications 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 nonmitigation to 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.
...