Skip to Content
Version 1.2 by Helena on 2025/07/01 17:51
Show last authors
1 {{box title="**Contents**"}}
2 {{toc/}}
3 {{/box}}
4
5 **Revision History**
6
7 (% style="width:991.835px" %)
8 |(% style="width:154px" %)**Revision ** |(% style="width:249px" %)**Date ** |(% style="width:586px" %)**Contents **
9 |(% style="width:154px" %)DRAFT 1.0|(% style="width:249px" %)December 2024|(% style="width:586px" %)Draft release updated for SDMX 3.1 for public consultation
10 |(% style="width:154px" %)1.0|(% style="width:249px" %)May 2025|(% style="width:586px" %)Public release for SDMX 3.1
11
12 = 1. Overview =
13
14 SDMX 3.1 is a minor revision to the SDMX 3.0 Standard which introduces a limited set of changes, which cover the following:
15
16 Information Model
17
18 * Support for Dataflows to reference a subset of Dimensions from a Data Structure Definition
19 * Simplification to Data Constraints
20 * Addition of Availability Constraints
21
22 1. Documentation
23
24 Registering Reference Metadata removed from documentation, to align with XML Registration object which is unable to reference a Metadata Provision, and REST API which is unable to query for registered reference metadata sources.
25
26 Breaking Changes
27
28 * Remove version property on Categorisation
29 * Removal of Advanced Release Calendar
30
31 Content of the Document
32
33 The remainder of this document contains a summary of the changes. More detailed information can be found in the SDMX 3.1 Technical Specifications, in particular:
34
35 Section 2 – Information Model
36
37 Section 5 – Registry Specification
38
39 Section 6 – Technical Notes
40
41 SDMX TWG GitHub for the REST API and the XML and JSON formats
42
43 = 2. Summary of Breaking Changes in 3.1 =
44
45 Version 3.1 introduces breaking changes, in the model in the following areas:
46
47 == 2.1 Removal of Advanced Release Calendar ==
48
49 The Data Constraint was simplified to become a cohesive structural artefact focussed solely on the restriction of values that can be reported. As part of this remodelling the Advanced Release Calendar was removed as it does not play a restrictive role.
50
51 //Guidance for Implementors//
52
53 Reference Metadata reported against a Dataflow and / or Provision Agreement can be used as an alternative to the Advanced Release Calendar.
54
55 1. //2.2 Removal of Version on Categorisation//
56
57 The Categorisation structural artefact has no use case for undergoing version changes, the version was therefore removed.
58
59
60 //Guidance for Implementors//
61
62 If multiple versions of a Categorisation exist where the source or target differs, these Categorisations should be given a unique ID.
63
64 1.
65 11. Information Model
66
67 The changes to the information model support two distinct use cases:
68
69 1. Horizontally complex Data Structure Definitions (DSDs)
70 1. Additional cohesion to the Data Constraints model
71
72 These changes are described in below.
73
74 1. //3.1 Horizontally Complex Data Structure Definitions//
75
76 An explanation of this use case, with additional details can be found under Section 6 - Technical Notes, under heading ‘10.3 Dimension Constraint’.
77
78 The following changes to the model have been made to satisfy this use case.
79
80 1.
81 11.
82 111.
83 1111. Data Structure Definition
84
85 The Data Structure Definition has a new ‘evolving structure’ property, this is a Boolean property, when set to ‘true’ it indicates to the users of the DSD that new Dimensions may be added without the DSD undergoing a change to its major version number.
86
87 1.
88 11.
89 111.
90 1111. Dataflow
91
92 The Dataflow has a new Dimension Constraint property, which is used to reference a subset of Dimensions which it uses from the referenced DSD.
93
94 The Dimension Constraint fixes the Dimensions of the Dataflow enabling the referenced DSD to have new Dimensions added without the need to change the major version number.
95
96 The Dimension Constraint property is only required if the DSD sets the evolving structure property to true.
97
98 1. //3.2 Constraint Cohesion//
99
100 The Constraint model in SDMX 3.1 has been made more cohesive by separating the Data Constraint into two distinct structures; the Data Constraint which describes reporting restrictions, and the Availability Constraint, which describes data content from a data source. In SDMX 3.0 these distinctions were made using the ‘type’ property on a Data Constraint.
101
102 1.
103 11.
104 111.
105 1111. Data Constraint
106
107 The Data Constraint has had the ‘type’ property removed; the Data Constraint in SDMX 3.1 is always used to describe restrictions on content for data reporting purposes.
108
109 The attachment of the Data Constraint in SDMX 3.0 included Data Sources, in SDMX 3.1 these attachments have been removed as these are not relevant for restricting reported data.
110
111 1.
112 11.
113 111.
114 1111. Availability Constraint
115
116 The Availability Constraint is a new Structure introduced to describe data that exists, it is generated in the response to the Availability REST API. It is not a maintained structure, and as such has no maintenance agency, identity or version