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

Summary

Details

Page properties
Content
... ... @@ -9,108 +9,4 @@
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 -= 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
12 +