Version compatibility

DDEX standards come in different versions. Over time, DDEX members and licensees have identified additional requirements that are then added into subsequent versions of a specific standard. 

DDEX standards with the same major version number (that’s the “3” of “3.2” for instance) are usually backwards compatible; there are, however, a few exceptions (see below). 

DDEX standards with different major version numbers are usually not backwards compatible as major version updates imply a significant change of the message structure.

Backwards compatible

The term “backwards compatible” indicates that messages that conforming to the older version may be processed by systems implementing the newer version of the standard. This is the case, e.g. if tags are added to the message structure, but that no tags either removed or renamed. 

Backwards compatibility is also given if allowed values are added, but if no allowed value is either removed or renamed.

As a consequence, 

  • A Message in version 3.2 of a specific standard will be able to be processed with no change by a processor for version 3.3; and

  • A Message in version 3.3 of a specific standard will be able to be processed with no change by a processor for version 3.2, provided that none of the new features of version 3.3 are being used or are important for either party.

Incompatible minor versions

There are a few cases where standards with the same major versions number may not be backwards compatible:

  • If DDEX considers a non-backwards compatible update to be not significant enough to change the major version number. Examples include cases where tags are moved from one location to another in the same message, and where tags or allowed values that are not used any more (or are in very little use) are removed;

  • If a bug was fixed – for instance an ERN product message in version 3.4.1 may not be processable by a program written for version 3.4. Note: that such bug fixes typically only affect a small aspect and, thus, many applications would still be able to process old files, and that any changes are usually small and, thus, updating the relevant code is usually be comparatively simple. 

Allowed values

While DDEX has agreed to not remove allowed values from the DDEX Data Dictionary this does not mean that a specific standard may, sometimes, remove allowed values from a specific standard if such values are considered by DDEX to be not used in that context. More often DDEX decides to mark a specific value as “deprecated”. This means that the allowed value remains valid and can continue to be used – but users are advised to not use (or phase out) such values. Deprecating allowed values can even happen without declaring a new version of a standard.

List of non-backwards compatible minor versions

The following minor version updates are not backwards compatible (the table does not list compatible changes or changes to the name of XML data types that do not result in compatibility issues):



Non-backwards compatible change


3.7.x → 3.8.

  • Removal of the CatalogListMessage;

  • Removal of attributes from various pre-order dates;

  • Change the data type of sequence numbers to be integers.

4.2 → 4.3

  • Addition of a mandatory AvsVersionId attribute to all messages’ root tag; and

  • Move of the following tags into the new SoundRecordingEdition tag: Type, ResourceId, PLine, RecordingMode and TechnicalDetails


1.0 → 1.2

  • Addition of a mandatory AvsVersionId attribute to all messages’ root tag


1.4 → 1.5

  • A number of composites, including RightsController. were moved “up a level” from SoundRecordingDetailsByTerritory to SoundRecording

Notes: RDR-N 1.4 is formally called MLC 1.4; MWN 1.1 was never published and bugfixes are not listed in the above table.