Skip to Content
Last modified by Artur on 2025/09/30 12:30
From version 5.1
edited by Helena
on 2025/06/06 16:56
Change comment: There is no comment for this version
To version 9.1
edited by Helena
on 2025/06/06 17:05
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -14,7 +14,7 @@
14 14  
15 15  The SDMX Technical Specifications are organised into several discrete sections.
16 16  
17 -The following are published on the SDMX website ([[__https:~~/~~/www.sdmx.org__>>url:https://www.sdmx.org/]][[)>>url:https://www.sdmx.org/]]:
17 +The following are published on the SDMX website ([[__https:~~/~~/www.sdmx.org__>>https://https:www.sdmx.org]]):
18 18  
19 19  **Section 1** **Framework for SDMX Technical Standards** – this document providing an introduction to the technical standards.
20 20  
... ... @@ -84,7 +84,8 @@
84 84  
85 85  SDMX version 3.0 introduces new features, improvements and changes to the Standard in the following key areas:
86 86  
87 -==== Information Model ====
87 +(% class="wikigeneratedid" id="HInformationModel" %)
88 +**Information Model**
88 88  
89 89  * Simplification and improvement of the reference metadata model
90 90  * Support for microdata
... ... @@ -94,11 +94,13 @@
94 94  * Improvements to code hierarchies for data discovery
95 95  * Improvements to constraints
96 96  
97 -==== Versioning of Structural Metadata Artefacts ====
98 +(% class="wikigeneratedid" id="HVersioningofStructuralMetadataArtefacts" %)
99 +**Versioning of Structural Metadata Artefacts**
98 98  
99 99  • Adoption of the three-number semantic versioning standard for structural metadata artefacts ([[__https:~~/~~/semver.org__>>https://https:semver.org]])
100 100  
101 -==== REST Web Services Application Programming Interface (API) ====
103 +(% class="wikigeneratedid" id="HRESTWebServicesApplicationProgrammingInterface28API29" %)
104 +**REST Web Services Application Programming Interface (API)**
102 102  
103 103  * Change to a single ‘structure’ resource for structure queries simplifying the REST API specification by reducing the number of resources to five
104 104  * Improvements to data queries
... ... @@ -105,11 +105,13 @@
105 105  * Improvements to reference metadata queries
106 106  * Support for structural metadata maintenance using HTTP PUT, POST and DELETE verbs
107 107  
108 -==== SOAP Web Services API ====
111 +(% class="wikigeneratedid" id="HSOAPWebServicesAPI" %)
112 +**SOAP Web Services API**
109 109  
110 110  • The SOAP web services API has been deprecated with version 3.0 standardising on REST
111 111  
112 -==== XML, JSON, CSV and EDI Transmission formats ====
116 +(% class="wikigeneratedid" id="HXML2CJSON2CCSVandEDITransmissionformats" %)
117 +**XML, JSON, CSV and EDI Transmission formats**
113 113  
114 114  * The SDMX-ML, SDMX-JSON and SDMX-CSV specifications have been extended and modified where needed to support the new features and changes such as reference metadata and microdata
115 115  * Obsolete SDMX-ML data message variants including Generic, Compact, Utility and Cross-sectional have been deprecated standardising on Structure Specific Data as the sole XML format for data exchange
... ... @@ -136,10 +136,10 @@
136 136  (% class="wikigeneratedid" id="HInformationModel-1" %)
137 137  **Information Model**
138 138  
139 -* Addition of Dimension Constraint property to a Dataflow//  //
140 -* Addition of evolving structure property to a Data Structure Definition//  //
141 -* Remove version property on Categorisation//  //
142 -* Simplification of Constraints o Removal of Advanced Release Calendar//  //
144 +* Addition of Dimension Constraint property to a Dataflow
145 +* Addition of evolving structure property to a Data Structure Definition
146 +* Remove version property on Categorisation
147 +* Simplification of Constraints o Removal of Advanced Release Calendar
143 143  
144 144  o Removal of Role, Data Constraints only restrict data that can be reported// //o Restrict constraint targets to Identifiable structures (not URLs) o Addition of Availability Constraint to define actual data
145 145  
... ... @@ -201,7 +201,6 @@
201 201  
202 202  The formal objects in the information model are presented schematically in Figure 1, and are discussed in more detail elsewhere in this document.
203 203  
204 -[[image:SDMX_3-1-0_SECTION_1_FINAL_6728d8d4.png||height="829" width="606"]]
205 205  
206 206  **Figure 1: High Level Schematic of Major Artefacts in the SDMX 3.0 Information Model**
207 207  
... ... @@ -235,7 +235,7 @@
235 235  * //**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.
236 236  * //**Metadataflow Definition:**// A metadata flow definition is very similar to a data flow definition, but describes, categorises, and constrains metadata sets.
237 237  * //**Data Provider: **//An organization which produces data is termed a data provider.
238 -* //**Metadata Provider: **//An organization which produces reference metadata is termed a metadata provider.//  //
242 +* //**Metadata Provider: **//An organization which produces reference metadata is termed a metadata provider.
239 239  * //**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.
240 240  * //**Data Constraint:**// Used to restrict content (such as enumerations) and are used by provision agreements, data flows, data structure definitions in order to provide a set of reporting restrictions in the context of a collection
241 241  * //**Metadata Constraint:**// Used to restrict content (such as enumerations) and are used by metadata provision agreements, metadata flows, metadata structure definitions in order to provide a set of reporting restrictions in the context of a collection
SUZ.Methodology.Code.MethodologyClass[0]