The standard alone is not sufficient to ensure that the promising potential is more than just advertising messages, but can actually be realised in practice. Processes have to be adapted, tools developed, and comprehensive thinking fostered. OTX alone does not ensure exchangeability. Here exchangeability means the use of unaltered OTX documents in various target systems. Put another way: The same testing logic has to be executable in a wide variety of systems and lead to the same functional results. In order to ensure this exchangeability, the test sequences (OTX documents) have to meet the following criteria:

Validity
Completeness
Target system independence

Valid OTX data must use the correct syntax — corresponding to the data model — and not violate any critical semantic checker rules. This is not a problem in most cases. Mistakes that occur here tend to be gross errors that are quickly located.

Furthermore, a test sequence is complete when the entire testing logic exists in OTX. Problem: The definition of what the testing logic encompasses depends on the specific case. Opinions can vary widely. Ultimately, the question is what one wants to achieve with OTX. Two extreme cases illustrate this point: In the first, OTX merely calls a function in an external system that contains the entire testing logic. In the second case, the entire tester including the HMI, administration of roles etc. exists in OTX. The first case may be valid, but is not complete and therefore also not exchangeable. The second case is both valid and complete, but pushes the boundaries of OTX's expressiveness; OTX was not made for this. It has been shown in practice that the testing logic stored in OTX should approximately correspond to the technical knowledge of an adept person responsible for a component. Once the testing logic is clearly delimited, completeness also includes that all elements referenced in OTX are present and accessible. For example, one could call a procedure that does not exist in OTX at all, but is somehow linked to the external method of a test standards library at runtime.

OTX must not contain any target system dependent data. Otherwise it may be valid but is not exchangeable. Target system independence begins where specific environments with specific implementations are needed to execute the sequence. Since a sequence is always executed on a target system, this dependency exists in all cases. The configuration data required for this cannot not be within but must be stored outside the OTX documents; see OTX Mapping. A Place where target system dependent data can be stored is what are called MetaData. MetaData can be stored on almost all elements in OTX, thereby transporting additional data such as release versions or procedure identifications at will within the OTX document. However, these data are not permitted to influence the runtime behaviour of the testing logic. A simple test: After erasing all MetaData, the sequence still has to be executable and the runtime behaviour is not permitted to change. The interface between OTX and the outside world (procedure parameters, context and status variables, screen parameters etc.) is another potential doorway for target system dependence. Only convertible data types such as Boolean, Integer, Float, String, ByteField, List, Map, Enumeration and Structure may be used here.

In summary, it can be said that OTX data input is only truly compliant With the ISO 13209 standard if it is valid, complete and target system independent. All tools described here generate and process standard compliant OTX exclusively. That being said, there certainly are meaningful cases using valid OTX that is incomplete and target system dependent. However, exchangeability across process boundaries with different tool landscapes is then no longer assured.