Skip to Content
Last modified by Helena on 2025/09/10 11:19
From version 3.1
edited by Helena
on 2025/05/14 15:17
Change comment: There is no comment for this version
To version 4.7
edited by Helena
on 2025/05/14 15:26
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -1 Introduction
1 +SDMX STANDARDS: SECTION 1
Content
... ... @@ -1,16 +1,21 @@
1 +{{box title="**Contents**"}}
2 +{{toc/}}
3 +{{/box}}
4 +
1 1  **Revision History**
2 2  
3 -|**Revision**|**Date**|**Contents**
4 -|DRAFT 1.0|May 2021|Draft release updated for SDMX 3.0 for public consultation
5 -|1.0|October 2021|Public release for SDMX 3.0
7 +(% style="width:769.039px" %)
8 +|(% style="width:144px" %)**Revision**|(% style="width:195px" %)**Date**|(% style="width:426px" %)**Contents**
9 +|(% style="width:144px" %)DRAFT 1.0|(% style="width:195px" %)May 2021|(% style="width:426px" %)Draft release updated for SDMX 3.0 for public consultation
10 +|(% style="width:144px" %)1.0|(% style="width:195px" %)October 2021|(% style="width:426px" %)Public release for SDMX 3.0
6 6  
7 -= {{id name="_Toc56226"/}}1 Introduction =
12 += 1 Introduction =
8 8  
9 9  The Statistical Data and Metadata Exchange (SDMX) initiative (https:~/~/www.sdmx.org) sets 3 standards that can facilitate the exchange of statistical data and metadata using modern 4 information technology.
10 10  
11 11  The SDMX Technical Specifications are organised into several discrete sections.
12 12  
13 -The following are published on the SDMX website ( __[[https:~~/~~/www.sdmx.org>>url:https://www.sdmx.org/]]__ [[)>>url:https://www.sdmx.org/]]:
18 +The following are published on the SDMX website ([[__https:~~/~~/www.sdmx.org__>>https://https:www.sdmx.org]]).
14 14  
15 15  **Section 1** **Framework for SDMX Technical Standards** – this document providing an introduction to the technical standards.
16 16  
... ... @@ -20,7 +20,7 @@
20 20  
21 21  **Section 6** **SDMX Technical Notes** – detailed technical guidance for implementors of the SDMX standard.
22 22  
23 -The following are published on the GitHub repository of the SDMX Standards Technical Working Group ( __[[https:~~/~~/github.com/sdmx>>url:https://github.com/sdmx]][[->>url:https://github.com/sdmx-twg]][[twg>>url:https://github.com/sdmx-twg]]__ [[)>>url:https://github.com/sdmx-twg]]:
28 +The following are published on the GitHub repository of the SDMX Standards Technical Working Group ( __[[https:~~/~~/github.com/sdmx-twg>>https://github.com/sdmx-twg]]) :__
24 24  
25 25  === sdmx-twg/sdmx-rest – REST API ===
26 26  
... ... @@ -48,7 +48,7 @@
48 48  
49 49  In July 2020 the SDMX 2.1 specifications were revised to add support for the Validation and Transformation Language (VTL). For 3.0, the VTL specification has been updated to align with changes to the information model and other modifications to the Standard such as the introduction of Semantic Versioning for the versioning of structural metadata artefacts. Section 2 (Information Model) sets out details of the ‘Transformation and Expressions’ package for defining and managing VTL 2.0 programs and Section 6 (Technical Notes) provides detailed guidance on implementing and using VTL with SDMX.
50 50  
51 -= {{id name="_Toc56227"/}}2 Change History =
56 += 2 Change History =
52 52  
53 53  The 2.0 version of this standard represented a significant increase in scope, and also provided more complete support in those areas covered in the version 1.0 specification. Version 2.0 of this standard is backward-compatible with version 1.0, so that existing implementations can be easily migrated to conformance with version 2.0.
54 54  
... ... @@ -56,39 +56,28 @@
56 56  
57 57  The 3.0 version incorporates new features, improvements and changes arising from the collective knowledge gained from a decade of operating experience with the 2.1 standard. In pursuit of modernisation and simplification, features considered obsolete have been deprecated – in particular the EDI transmission format, the lesser-used XML data messages and the SOAP web services API. Many areas remain backwardly compatible with 2.1, but there are some breaking changes where the information model has been redesigned to better support practical use case. Structure mapping and reference metadata are examples. The opportunity has been taken to revise the RESTful web services API which is also not backwardly compatible, but benefits from a rationalisation and better organisations of resources, and a much richer data query URL syntax.
58 58  
59 -== {{id name="_Toc56228"/}}2.1 Major Changes from 1.0 to 2.0 ==
64 +== 2.1 Major Changes from 1.0 to 2.0 ==
60 60  
61 61  * **Reference Metadata**: In addition to describing and specifying data structures and formats (along with related structural metadata), the version 2.0 specification also provides for the exchange of metadata which is distinct from the structural metadata in the 1.0 version. This category includes “reference” metadata (regarding data quality, methodology, and similar types – it can be configured by the user to include whatever concepts require reporting); metadata related to data provisioning (release calendar information, description of the data and metadata provided, etc.); and metadata relevant to the exchange of categorization schemes.
62 -* **SDMX Registry**: Provision is made in the 2.0 standard for standard communication with registry services, to support a data-sharing model of statistical exchange. These services include registration of data and metadata, querying of registered data and metadata, and subscription/notification.
67 +* **SDMX Registry**: Provision is made in the 2.0 standard for standard communication with registry services, to support a data-sharing model of statistical exchange. These services include registration of data and metadata, querying of registered data and metadata, and subscription.
68 +* **Structural Metadata**: The support for exchange of statistical data and related structural metadata has been expanded. Some support is provided for qualitative data; data cube structures are described; hierarchical code lists are supported; relationships between data structures can be expressed, providing support for extensibility of data structures; 101 and the description of functional dependencies within cubes are supported.
63 63  
64 -• **Structural Metadata**: The support for exchange of statistical data and related structural metadata has been expanded. Some support is provided for qualitative data; data cube structures are described; hierarchical code lists are supported; relationships between data structures can be expressed, providing support for extensibility of data structures; 101 and the description of functional dependencies within cubes are supported.
70 +== 2.2 Major Changes from 2.0 to 2.1 ==
65 65  
66 -== {{id name="_Toc56229"/}}2.2 Major Changes from 2.0 to 2.1 ==
72 +* **Simplification of the data structure definition - specific message types:** Both time series (version 2.0 Compact) and non-time series data sets (version 2.0 Cross Sectional) use the same underlying structure for a structure-specific formatted message, which is specific to the Data Structure Definition of the data set.
73 +* **Simplification and better support for the metadata structure: **New use cases have been reported and these are now supported by a re-modelled metadata structure definition.
74 +* **Web-Services-Oriented Changes:** Several organizations have been implementing web services applications using SDMX, and these implementations have resulted in several changes to the specifications. Because the nature of SDMX web services could not be anticipated at the time of the original drafting of the specifications, the web services guidelines have been completely re-developed.
75 +* **Presentational Changes: **Much work has gone into using various technologies for the visualization of SDMX data and metadata, and some changes have been proposed as a result, to better leverage this graphical visualization. These changes are largely to leverage the Cross-domain Concepts of the Content Oriented Guidelines.
76 +* **Consistency Issues:** There have been some areas where the draft specifications were inconsistent in minor ways, and these have been addressed.
77 +* **Clarifications in Documentation:** In some cases, it has been identified that the documentation of specific fields within the standard needed clarification and elaboration, and these issues have been addressed.
78 +* **Optimization for XML Technologies:** Implementation has shown that it is possible to better organize the XML schemas for use within common technology development tools which work with XML. These changes are primarily focused on leveraging the object oriented features of W3C XML Schema to allow for easier processing of SDMX data and metadata.
79 +* **Consistency between the SDMX-ML and the SDMX Information Model: **Certain aspects of the XML schemas and UML model have been more closely aligned, to allow for easier comprehension of the SDMX model.
80 +* **Technical Bugs:** Some minor technical bugs have been identified in the registry interfaces and elsewhere. These bugs have been addressed.
81 +* **Support for Non-Time-Series Data in the Generic Format: **One area which has been extended is the ability to express non-time-series data as part of the generic data message.
82 +* **Support for partial item schemes such as a code list: **The concept of a partial (sub set) item scheme such as a partial code list for use in exchange scenarios has been introduced**.**
67 67  
68 -• **Web-Services-Oriented Changes:** Several organizations have been implementing web services applications using SDMX, and these implementations have resulted in several changes to the specifications. Because the nature of SDMX web services could not be anticipated at the time of the original drafting of the specifications, the web services guidelines have been completely re-developed.
84 +== 2.3 Major Changes from 2.1 to 3.0 ==
69 69  
70 -• **Presentational Changes: **Much work has gone into using various technologies for the visualization of SDMX data and metadata, and some changes have been proposed as a result, to better leverage this graphical visualization. These changes are largely to leverage the Cross-domain Concepts of the Content Oriented Guidelines.
71 -
72 -• **Consistency Issues:** There have been some areas where the draft specifications were inconsistent in minor ways, and these have been addressed.
73 -
74 -• **Clarifications in Documentation:** In some cases, it has been identified that the documentation of specific fields within the standard needed clarification and elaboration, and these issues have been addressed.
75 -
76 -• **Optimization for XML Technologies:** Implementation has shown that it is possible to better organize the XML schemas for use within common technology development tools which work with XML. These changes are primarily focused on leveraging the object oriented features of W3C XML Schema to allow for easier processing of SDMX data and metadata.
77 -
78 -• **Consistency between the SDMX-ML and the SDMX Information Model: **Certain aspects of the XML schemas and UML model have been more closely aligned, to allow for easier comprehension of the SDMX model.
79 -
80 -• **Technical Bugs:** Some minor technical bugs have been identified in the registry interfaces and elsewhere. These bugs have been addressed.
81 -
82 -• **Support for Non-Time-Series Data in the Generic Format: **One area which has been extended is the ability to express non-time-series data as part of the generic data message.
83 -
84 -==== • **Simplification of the data structure definition - specific message types: **Both time series (version 2.0 Compact) and non-time series data sets (version 2.0 Cross Sectional) use the same underlying structure for a structure-specific formatted message, which is specific to the Data Structure Definition of the data set. ====
85 -
86 -• **Simplification and better support for the metadata structure: **New use cases have been reported and these are now supported by a re-modelled metadata structure definition.
87 -
88 -• **Support for partial item schemes such as a code list: **The concept of a partial (sub set) item scheme such as a partial code list for use in exchange scenarios has been introduced**.**
89 -
90 -== {{id name="_Toc56230"/}}2.3 Major Changes from 2.1 to 3.0 ==
91 -
92 92  SDMX version 3.0 introduces new features, improvements and changes to the Standard in the following key areas:
93 93  
94 94  ===== Information Model =====
... ... @@ -103,7 +103,7 @@
103 103  
104 104  ===== Versioning of Structural Metadata Artefacts =====
105 105  
106 -• Adoption of the three-number semantic versioning standard for structural metadata artefacts [[(>>url:https://semver.org/]] __[[https:~~/~~/semver.org>>url:https://semver.org/]] __[[)>>url:https://semver.org/]]
100 +* Adoption of the three-number semantic versioning standard for structural metadata artefacts (__[[https:~~/~~/semver.org>>url:https://semver.org/]])__
107 107  
108 108  ===== REST Web Services Application Programming Interface (API) =====
109 109  
... ... @@ -114,7 +114,7 @@
114 114  
115 115  ===== SOAP Web Services API =====
116 116  
117 -• The SOAP web services API has been deprecated with version 3.0 standardising on REST** **
111 +* The SOAP web services API has been deprecated with version 3.0 standardising on REST
118 118  
119 119  ===== XML, JSON, CSV and EDI Transmission formats =====
120 120  
... ... @@ -228,7 +228,7 @@
228 228  * //**Dataflow Definition:**// In SDMX, data sets are reported or disseminated according to a data flow definition. The data flow definition identifies the data structure definition and may be associated with one or more subject matter domains via a Categorisation (this facilitates the search for data according to organised category schemes). Constraints, in terms of reporting periodicity or sub set of possible keys that are allowed in a data set, may be attached to the data flow definition.
229 229  * //**Metadataflow Definition:**// A metadata flow definition is very similar to a data flow definition, but describes, categorises, and constrains metadata sets.
230 230  * //**Data Provider: **//An organization which produces data is termed a data provider.
231 -* //**Metadata Provider: **//An organization which produces reference metadata is termed a metadata provider.//  //
225 +* //**Metadata Provider: **//An organization which produces reference metadata is termed a metadata provider.//  //
232 232  * //**Provision Agreement (Metadata Provision Agreement):**// The set of information which describes the way in which data sets and metadata sets are provided by a data/metadata provider. A provision agreement can be constrained in much the same way as a data or metadata flow definition. Thus, a data provider can express the fact that it provides a particular data flow covering a specific set of countries and topics, Importantly, the actual source of registered data or metadata is attached to the provision agreement (in terms of a URL). The term “agreement” is used because this information can be understood as the basis of a “service-level agreement”. In SDMX, however, this is informational metadata to support the technical systems, as opposed to any sort of contractual information (which is outside the scope of a technical specification). In version 3.0, metadata provision agreement and data provision agreement are two separate artefacts.
233 233  * //**Constraint:**// Data and Metadata Constraints describe a subset of a data source or metadata source, and may also provide information about scheduled releases of data. They are associated with data / metadata providers, provision agreements, data flows, metadataflows, data structure definitions and metadata structure definitions.
234 234  * //**Structure Map: **//Structure maps describes a mapping between data structure definitions or dataflows for the purpose of transforming a data set into a different structure. The mapping rules are defined using one or more component maps which each map in turn describes how one or more components from the source data 534 structure definition map to one or more components in that of the target. Represent maps act as lookup tables and specific provision is made for mapping dates and times.