DDEX development and maintenance

DDEX standards are developed in accordance with a well-defined and well-tested process. This process addresses the need for standards to be stable and properly peer-reviewed while operating in an ever-faster changing commercial environment. It also ensures that everyone’s voice is heard and that no single or group of organisation(s) can exert undue influence over the development of the standards.

 Development steps

DDEX follows these steps whether developing a brand new standard or maintaining an existing one:

  • When a requirement is identified it is documented; 

  • The DDEX Board then assigns the requirement to a technical Working Group to work on; 

  • The Working Group meets to arrive at a technical solution to the requirement by creating a Working Draft document;

  • Once complete the Working Draft is promoted to Committee Draft; 

  • The Committee Draft is made available to all DDEX members for 30 days for comment;

  • The comments are then reviewed by the Technical Management Group (TMG) and if accepted a Draft Standard created;

  • If the TMG rejects comments the Committee Draft is returned to Working Draft status and the relevant Working Group asked to resolve the issue(s);

  • Otherwise, the TMG recommends the Draft Standard to the Board for approval;

  • Within 7 days the Board meets to approve or reject the Draft Standard; and

  • Assuming approval is given by the Board, the Draft Standard is declared a DDEX Standard and published on this knowledge base.

 Decision making at DDEX

DDEX attempts as much as possible to make decisions unanimously. 

However, this is not always possible, so then, decisions are made by consensus. DDEX broadly uses the International Organisation for Standards (“ISO”) definition of consensus which is:

“the absence of sustained opposition to substantial issues by any important part of the concerned interests and by a process that involves seeking to take into account the views of all parties concerned and to reconcile any conflicting arguments. Consensus need not imply unanimity and is declared, if necessary, by the relevant Chair”.

 Versioning

New versions of DDEX standards are created in response to new and changing requirements. For this reason, each DDEX standard comes in different versions.

Backwards compatibility

With a few exceptions, each DDEX standard is backwards compatible. For example:

  • A message in version 3.2 of a specific standard can be processed (with no change) by a processor for version 3.3; and

  • A message in version 3.3 of a specific standard can be processed (with no change) by a processor for version 3.2, provided none of the version 3.3 features is used by either party.

Backwards compatibility exceptions

There are two cases where two messages created in accordance with a standard but created in accordance with two different versions may not be compatible with each other:

  • If the major version number is different:

    • For example, a DSR message in version 3.2 cannot be read by a processor written for version 4.1; and

  • If a major bug was fixed:

    • For example, an ERN message in version 3.4.1 may not be processed by a program written for version 3.4; and

    • Usually, major bug fixes affect only one small aspect of a standard, and many applications would still be able to process old files and any changes are usually small so updating the relevant code may be relatively easy.

Search