Skip to Content
Last modified by Artur on 2025/09/13 19:50
From version 1.1
edited by Helena
on 2025/07/01 17:47
Change comment: There is no comment for this version
To version 1.2
edited by Helena
on 2025/07/01 17:51
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -9,4 +9,108 @@
9 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 10  |(% style="width:154px" %)1.0|(% style="width:249px" %)May 2025|(% style="width:586px" %)Public release for SDMX 3.1
11 11  
12 -
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