11 Transforming between versions of SDMX

Last modified by Helena on 2025/07/20 12:46

11.1 Scope

The scope of this section is to define both best practices and mandatory behaviour for specific aspects of transformation between different versions of SDMX.

11.2 Compatibility and new DSD features

The following table provides an overview of the backwards compatibility between SDMX 3.0 and 2.1.

SDMX 3.0 featureSDMX 2.1 compatibilityComments
Multiple Measures

Create a Measure Dimension Or
Model Measures as Attributes

For a Measure Dimensions, all Concepts must reside in the same Concept Scheme
Arrays for valuesCannot be supportedArrays are always reported in a verbose format, even if one value is reported
Measure RelationshipCan be ignored, as it does not affect dataset format 
Metadata AttributesCan be created as Data AttributesNot for extended facets
Multilingual ComponentsCannot be supported 
No MeasureCan only be emulated by ignoring the Primary Measure value 
Use extended CodelistA new Codelist with all Codes must be created 
Sentinel valuesCannot be supported in the DSDRules may be supported outside the DSD, in bilateral agreements

The following table illustrates forward compatibility issues from SDMX 2.1 to 3.0.

SDMX 2.1 featureSDMX 3.0 compatibilityComments
Measure Dimension

Create a Dimension with role ‘MEASURE
Or
Create multiple Measures from the Measure Dimension Concept Scheme

If the dataset has to resemble that of SDMX 2.1 Structure Specific, then the first option must be used
Primary Measure

Create one Measure with role
‘PRIMARY’; use id=”OBS_VALUE”