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.6
edited by Helena
on 2025/07/01 17:54
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -9,4 +9,92 @@
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 +**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 +Reference Metadata reported against a Dataflow and / or Provision Agreement can be used as an alternative to the Advanced Release Calendar.
53 +
54 +== 2.2 Removal of Version on Categorisation ==
55 +
56 +The Categorisation structural artefact has no use case for undergoing version changes, the version was therefore removed.
57 +
58 +//Guidance for Implementors//
59 +If multiple versions of a Categorisation exist where the source or target differs, these Categorisations should be given a unique ID.
60 +
61 += 3. Information Model =
62 +
63 +The changes to the information model support two distinct use cases:
64 +
65 +1. Horizontally complex Data Structure Definitions (DSDs)
66 +1. Additional cohesion to the Data Constraints model
67 +
68 +These changes are described in below.
69 +
70 +== 3.1 Horizontally Complex Data Structure Definitions ==
71 +
72 +An explanation of this use case, with additional details can be found under Section 6 - Technical Notes, under heading ‘10.3 Dimension Constraint’.
73 +
74 +The following changes to the model have been made to satisfy this use case.
75 +
76 +**Data Structure Definition**
77 +
78 +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.
79 +
80 +**Dataflow**
81 +
82 +The Dataflow has a new Dimension Constraint property, which is used to reference a subset of Dimensions which it uses from the referenced DSD.
83 +
84 +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.
85 +
86 +The Dimension Constraint property is only required if the DSD sets the evolving structure property to true.
87 +
88 +== 3.2 Constraint Cohesion ==
89 +
90 +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.
91 +
92 +**Data Constraint**
93 +
94 +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.
95 +
96 +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.
97 +
98 +**Availability Constraint**
99 +
100 +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