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

Summary

Details

Page properties
Content
... ... @@ -9,7 +9,7 @@
9 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 10  |(% style="width:144px" %)1.0|(% style="width:195px" %)October 2021|(% style="width:426px" %)Public release for SDMX 3.0
11 11  
12 -= {{id name="_Toc56226"/}}1 Introduction =
12 += 1 Introduction =
13 13  
14 14  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.
15 15  
... ... @@ -25,21 +25,25 @@
25 25  
26 26  **Section 6** **SDMX Technical Notes** – detailed technical guidance for implementors of the SDMX standard.
27 27  
28 -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]]) :__
29 29  
30 -=== sdmx-twg/sdmx-rest – REST API ===
30 +(% class="wikigeneratedid" id="Hsdmx-twg2Fsdmx-rest2013RESTAPI" %)
31 +**sdmx-twg/sdmx-rest – REST API**
31 31  
32 32  Technical specifications for the SDMX RESTful web services application programming interfaces (API).
33 33  
34 -=== sdmx-twg/sdmx-ml – SDMX-ML ===
35 +(% class="wikigeneratedid" id="Hsdmx-twg2Fsdmx-ml2013SDMX-ML" %)
36 +**sdmx-twg/sdmx-ml – SDMX-ML**
35 35  
36 36  Technical specifications for the XML transmission format including XSD schemas, documentation and samples for data, structure and reference metadata messages.
37 37  
38 -=== sdmx-twg/sdmx-json – SDMX-JSON ===
40 +(% class="wikigeneratedid" id="Hsdmx-twg2Fsdmx-json2013SDMX-JSON" %)
41 +**sdmx-twg/sdmx-json – SDMX-JSON**
39 39  
40 40  Technical specifications for the JSON transmission format including documentation, schemas and samples for data, structure and reference metadata messages.
41 41  
42 -=== sdmx-twg/sdmx-csv – SDMX-CSV ===
45 +(% class="wikigeneratedid" id="Hsdmx-twg2Fsdmx-csv2013SDMX-CSV" %)
46 +**sdmx-twg/sdmx-csv – SDMX-CSV**
43 43  
44 44  Technical specifications for the SDMX-CSV transmission format for ‘comma-separated values’ (CSV) data and reference metadata.
45 45  
... ... @@ -53,7 +53,7 @@
53 53  
54 54  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.
55 55  
56 -= {{id name="_Toc56227"/}}2 Change History =
60 += 2 Change History =
57 57  
58 58  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.
59 59  
... ... @@ -61,42 +61,31 @@
61 61  
62 62  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.
63 63  
64 -== {{id name="_Toc56228"/}}2.1 Major Changes from 1.0 to 2.0 ==
68 +== 2.1 Major Changes from 1.0 to 2.0 ==
65 65  
66 66  * **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.
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/notification.
71 +* **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.
72 +* **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.
68 68  
69 -• **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.
74 +== 2.2 Major Changes from 2.0 to 2.1 ==
70 70  
71 -== {{id name="_Toc56229"/}}2.2 Major Changes from 2.0 to 2.1 ==
76 +* **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.
77 +* **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.
78 +* **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.
79 +* **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.
80 +* **Consistency Issues:** There have been some areas where the draft specifications were inconsistent in minor ways, and these have been addressed.
81 +* **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.
82 +* **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.
83 +* **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.
84 +* **Technical Bugs:** Some minor technical bugs have been identified in the registry interfaces and elsewhere. These bugs have been addressed.
85 +* **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.
86 +* **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**.**
72 72  
73 -• **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.
88 +== 2.3 Major Changes from 2.1 to 3.0 ==
74 74  
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 -
77 -• **Consistency Issues:** There have been some areas where the draft specifications were inconsistent in minor ways, and these have been addressed.
78 -
79 -• **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.
80 -
81 -• **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.
82 -
83 -• **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.
84 -
85 -• **Technical Bugs:** Some minor technical bugs have been identified in the registry interfaces and elsewhere. These bugs have been addressed.
86 -
87 -• **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.
88 -
89 -==== • **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. ====
90 -
91 -• **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.
92 -
93 -• **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**.**
94 -
95 -== {{id name="_Toc56230"/}}2.3 Major Changes from 2.1 to 3.0 ==
96 -
97 97  SDMX version 3.0 introduces new features, improvements and changes to the Standard in the following key areas:
98 98  
99 -===== Information Model =====
92 +=== Information Model ===
100 100  
101 101  * Simplification and improvement of the reference metadata model
102 102  * Support for microdata
... ... @@ -106,11 +106,11 @@
106 106  * Improvements to code hierarchies for data discovery
107 107  * Improvements to constraints
108 108  
109 -===== Versioning of Structural Metadata Artefacts =====
102 +=== Versioning of Structural Metadata Artefacts ===
110 110  
111 -• 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/]]
104 +* Adoption of the three-number semantic versioning standard for structural metadata artefacts (__[[https:~~/~~/semver.org>>url:https://semver.org/]])__
112 112  
113 -===== REST Web Services Application Programming Interface (API) =====
106 +=== REST Web Services Application Programming Interface (API) ===
114 114  
115 115  * Change to a single ‘structure’ resource for structure queries simplifying the REST API specification by reducing the number of resources to five
116 116  * Improvements to data queries
... ... @@ -117,11 +117,11 @@
117 117  * Improvements to reference metadata queries
118 118  * Support for structural metadata maintenance using HTTP PUT, POST and DELETE verbs
119 119  
120 -===== SOAP Web Services API =====
113 +=== SOAP Web Services API ===
121 121  
122 -• The SOAP web services API has been deprecated with version 3.0 standardising on REST** **
115 +* The SOAP web services API has been deprecated with version 3.0 standardising on REST
123 123  
124 -===== XML, JSON, CSV and EDI Transmission formats =====
117 +=== XML, JSON, CSV and EDI Transmission formats ===
125 125  
126 126  * 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
127 127  * 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
... ... @@ -143,9 +143,9 @@
143 143  
144 144  The SDMX 3.0 Major Changes document provides more information including an analysis of the breaking changes.
145 145  
146 -= {{id name="_Toc56231"/}}3 Processes and Business Scope =
139 += 3 Processes and Business Scope =
147 147  
148 -== {{id name="_Toc56232"/}}3.1 Process Patterns ==
141 +== 3.1 Process Patterns ==
149 149  
150 150  SDMX identifies three basic process patterns regarding the exchange of statistical data and metadata. These can be described as follows:
151 151  
... ... @@ -165,7 +165,7 @@
165 165  
166 166  It is important to note that SDMX is primarily focused on the //exchange// and //dissemination// of statistical data and metadata. There may also be many uses for the standard model and formats specified here in the context of internal processing of data that are not concerned with the exchange between organizations and users, however. It is felt that a clear, standard formatting of data and metadata for the purposes of exchange and dissemination can also facilitate internal processing by organizations and users, but this is not the focus of the specification.
167 167  
168 -== {{id name="_Toc56233"/}}3.2 SDMX and Process Automation ==
161 +== 3.2 SDMX and Process Automation ==
169 169  
170 170  Statistical data and metadata exchanges employ many different automated processes, but some are of more general interest than others. There are some common information technologies that are nearly ubiquitous within information systems today. SDMX aims to provide standards that are most useful for these automated processes and technologies.
171 171  
... ... @@ -181,7 +181,7 @@
181 181  
182 182  The SDMX standards specified here are designed to support the requirements of all of these automation processes and technologies.
183 183  
184 -== {{id name="_Toc56234"/}}3.3 Statistical Data and Metadata ==
177 +== 3.3 Statistical Data and Metadata ==
185 185  
186 186  To avoid confusion about which "data" and "metadata" are the intended content of the SDMX formats specified here, a statement of scope is offered. Statistical "data" are sets of often numeric observations which typically have time associated with them. They are associated with a set of metadata values, representing specific concepts, which act as identifiers and descriptors of the data. These metadata values and concepts can be understood as the named dimensions of a multi-dimensional co-ordinate system, describing what is often called a "cube" of data.
187 187  
... ... @@ -201,9 +201,9 @@
201 201  
202 202  [[image:SDMX 3-0-0 SECTION 1 FINAL-1.0_en_a3e7967f.png||height="921" width="629"]]
203 203  
204 -**Figure 1: High Level Schematic of Major Artefacts in the SDMX 3.0 Information Model**
197 +Figure 1: High Level Schematic of Major Artefacts in the SDMX 3.0 Information Model
205 205  
206 -== {{id name="_Toc56235"/}}3.4 The SDMX View of Statistical Exchange ==
199 +== 3.4 The SDMX View of Statistical Exchange ==
207 207  
208 208  Version 1.0 of ISO/TS 17369 SDMX covered statistical data sets and the metadata related to the structure of these data sets. This scope was useful in supporting the different models of statistical exchange (bilateral exchange, gateway exchange, and data-sharing) but was not by itself sufficient to support them completely. Versions 2.0 and 2.1 provide a much more complete view of statistical exchange, so that an open data-sharing model can be fully supported, and other models of exchange can be more completely automated. In order to produce technical standards that will support this increased scope, the SDMX Information Model provides a broader set of formal objects which describe the actors, processes, and resources within statistical exchanges.
209 209  
... ... @@ -233,27 +233,20 @@
233 233  * //**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.
234 234  * //**Metadataflow Definition:**// A metadata flow definition is very similar to a data flow definition, but describes, categorises, and constrains metadata sets.
235 235  * //**Data Provider: **//An organization which produces data is termed a data provider.
236 -* //**Metadata Provider: **//An organization which produces reference metadata is termed a metadata provider.//  //
229 +* //**Metadata Provider: **//An organization which produces reference metadata is termed a metadata provider.
237 237  * //**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.
238 238  * //**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.
239 239  * //**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.
233 +* //**Representation Map:**// Representation maps describe mappings between source value(s) and target value(s) where the values are restricted to those in a code list, value list or be of a certain type such as integer or string.
234 +* //**Item Scheme Map:**// An item scheme map describes mapping rules between any item scheme with the exception of code lists and value lists which use representation maps. The version 3.0 information model provides four item scheme maps: organisation scheme map, concept scheme map, category scheme map and reporting taxonomy map. Organisation scheme map and reporting scheme map have been omitted from the information model schematic in Figure 1.
235 +* //**Reporting Taxonomy: **//A reporting taxonomy allows an organisation to link (possibly in a hierarchical way) a number of cube or data flow definitions which together form a complete “report” of data or metadata. This supports primary reporting which often comprises multiple cubes of heterogeneous data, but may also support other collection and reporting functions. It also supports the specification of publications such as a yearbook, in terms of the data or metadata contained in the publication.
236 +* //**Process:**// The process class provides a way to model statistical processes as a set of interconnected //process steps.// Although not central to the exchange and dissemination of statistical data and metadata, having a shared description of processing allows for the interoperable exchange and dissemination of reference 556 metadata sets which describe processes-related concepts.
237 +* //**Hierarchy**//: Describes complex code hierarchies principally for data discovery purposes. The codes themselves are referenced from the code lists in which they are maintained.
238 +* //**Hierarchy Association**//: A hierarchy association links a hierarchy to something that needs it like a dimension. Furthermore, the linking can be specified in the context of another object such as a dimension in the context of a dataflow. Thus, a dimension in a data structure definition could have different hierarchies depending on the dataflow.
239 +* //**Transformation Scheme:**// A transformation scheme is a set of Validation and Transformation Language (VTL) transformations aimed at obtaining some meaningful results for the user (e.g., the validation of one or more data sets). The set of transformations is meant to be executed together (in the same run) and may contain any number of transformations in order to produce any number of results. Thus, a transformation scheme can be considered as a VTL ‘program’.
240 240  
241 -• //**Representation Map:**// Representation maps describe mappings between source value(s) and target value(s) where the values are restricted to those in a code list, value list or be of a certain type such as integer or string.
241 +== 3.5 SDMX Registry Services ==
242 242  
243 -• //**Item Scheme Map:**// An item scheme map describes mapping rules between any item scheme with the exception of code lists and value lists which use representation maps. The version 3.0 information model provides four item scheme maps: organisation scheme map, concept scheme map, category scheme map and reporting taxonomy map. Organisation scheme map and reporting scheme map have been omitted from the information model schematic in Figure 1.
244 -
245 -• //**Reporting Taxonomy: **//A reporting taxonomy allows an organisation to link (possibly in a hierarchical way) a number of cube or data flow definitions which together form a complete “report” of data or metadata. This supports primary reporting which often comprises multiple cubes of heterogeneous data, but may also support other collection and reporting functions. It also supports the specification of publications such as a yearbook, in terms of the data or metadata contained in the publication.
246 -
247 -• //**Process:**// The process class provides a way to model statistical processes as a set of interconnected //process steps.// Although not central to the exchange and dissemination of statistical data and metadata, having a shared description of processing allows for the interoperable exchange and dissemination of reference 556 metadata sets which describe processes-related concepts.
248 -
249 -• //**Hierarchy**//: Describes complex code hierarchies principally for data discovery purposes. The codes themselves are referenced from the code lists in which they are maintained.
250 -
251 -• //**Hierarchy Association**//: A hierarchy association links a hierarchy to something that needs it like a dimension. Furthermore, the linking can be specified in the context of another object such as a dimension in the context of a dataflow. Thus, a dimension in a data structure definition could have different hierarchies depending on the dataflow.
252 -
253 -• //**Transformation Scheme:**// A transformation scheme is a set of Validation and Transformation Language (VTL) transformations aimed at obtaining some meaningful results for the user (e.g., the validation of one or more data sets). The set of transformations is meant to be executed together (in the same run) and may contain any number of transformations in order to produce any number of results. Thus, a transformation scheme can be considered as a VTL ‘program’.
254 -
255 -== {{id name="_Toc56236"/}}3.5 SDMX Registry Services ==
256 -
257 257  In order to provide visibility into the large amount of data and metadata which exists within the SDMX model of statistical exchange, it is felt that an architecture based on a set of registry services is potentially useful. A “registry” – as understood in webservices terminology – is an application which maintains and stores metadata for querying, and which can be used by any other application in the network with sufficient access privileges (though note that the mechanism of access control is outside of the scope of the SDMX standard). It can be understood as the index of a distributed database or metadata repository which is made up of all the data provider’s data sets and reference metadata sets within a statistical community, located across the Internet or similar network.
258 258  
259 259  Note that the SDMX registry services are not concerned with the storage of data or reference metadata. The assumption is that data and reference metadata lives on the sites of its data and metadata providers. The SDMX registry services concern themselves with providing visibility of the data and reference metadata, and information needed to access the data and reference metadata. Thus, a registered data set will have its URL available in the registry, but not the data itself. An application which wishes to access that data would query the registry, perhaps by drilling down via a Category Scheme and Dataflow, for the URL of a registered data source, and then retrieve the data directly from the data provider (using an SDMX REST API query message or other mechanism).
... ... @@ -267,7 +267,7 @@
267 267  * //**Querying: **//The registry services have interfaces for querying the metadata contained in a registry, so that applications and users can discover the existence of data sets and reference metadata sets, structural metadata, the providers/agencies associated with those objects, and the provider agreements which describe how the data and metadata are made available, and how they are categorized.
268 268  * //**Subscription/Notification:**// It is possible to “subscribe” to specific objects in a registry, so that a notification will be sent to all subscribers whenever the registry objects are updated.
269 269  
270 -== {{id name="_Toc56237"/}}3.6 RESTful Web services ==
256 +== 3.6 RESTful Web services ==
271 271  
272 272  Web services allow computer applications to exchange data directly over the Internet, essentially allowing modular or distributed computing in a more flexible fashion than ever before. In order to allow web services to function, however, many standards are required: for requesting and supplying data; for expressing the enveloping data which is used to package exchanged data; for describing web services to one another, to allow for easy integration into applications that use other web services as data resources.
273 273  
... ... @@ -281,7 +281,7 @@
281 281  
282 282  The following conceptual example uses the ‘data’ resource to query a data repository for a series identified by the key ‘M.USD.EUR.SP00.A’ in the EXR (ECB exchange rates) Dataflow: https:~/~/ws-entry-point/data/dataflow/ECB/EXR/1.0.0/M.USD.EUR.SP00.A
283 283  
284 -= {{id name="_Toc56238"/}}4 The SDMX Information Model =
270 += 4 The SDMX Information Model =
285 285  
286 286  SDMX provides a way of modelling statistical data, and defines the set of metadata constructs used for this purpose. Because SDMX specifies a number of transmission formats for expressing data and structural metadata, the model is used as a mechanism for guaranteeing that transformation between the different formats is lossless. In this sense, all of the formats are syntax-bound expressions of the common information model.
287 287  
... ... @@ -299,9 +299,9 @@
299 299  
300 300  A full UML conceptual design of the information model is set out in Section 2 of the Technical Specifications.
301 301  
302 -= {{id name="_Toc56239"/}}5 The SDMX Transmission Formats =
288 += 5 The SDMX Transmission Formats =
303 303  
304 -== {{id name="_Toc56240"/}}5.1 SDMX-ML ==
290 +== 5.1 SDMX-ML ==
305 305  
306 306  SDMX-ML is the XML transmission format specification for exchanging structural metadata, data and reference metadata, and interacting with SDMX registry services. It is designed as a general-purpose format for all automation and data / metadata exchange tasks, and provides the most complete coverage.
307 307  
... ... @@ -313,12 +313,10 @@
313 313  Many XML tools and technologies have expectations about the functions performed by an XML schema, one of which is a very direct relationship between the XML constructs described in the XML schema and the tagged data in the XML instance. Strong data typing is also considered normal, supporting full validation of the tagged data. These message types are designed to support validation and other expected XML schema functions.
314 314  
315 315  1. //Generic Metadata~:// For the exchange of reference metadata sets. ‘Generic’ means the XML elements and XML attributes are the same regardless of the metadata set.
316 -1. //Registry~:// All of the possible interactions with the SDMX registry services are supported using SDMX-ML interfaces and REST API calls. Submission of structural metadata content, data / metadata registrations and subscriptions is performed by a synchronous exchange of documents – a “request” message answered by a
302 +1. //Registry~:// All of the possible interactions with the SDMX registry services are supported using SDMX-ML interfaces and REST API calls. Submission of structural metadata content, data / metadata registrations and subscriptions is performed by a synchronous exchange of documents – a “request” message answered by a “response” message.
317 317  
318 -“response” message.
304 +== 5.2 SDMX-JSON ==
319 319  
320 -== {{id name="_Toc56241"/}}5.2 SDMX-JSON ==
321 -
322 322  SDMX-JSON is the JSON transmission format specification for exchanging structural metadata, data and reference metadata. It provides an alternative to SDMX-ML and is most suited to applications like web data dissemination.
323 323  
324 324  SDMX-JSON messages serve the same function as those of the XML formats but have a different structure. For data, an important distinction is that they carry both component codes and labels which provides all the information needed to display the content in a single JSON response. The XML Structure-specific Data format by contrast carries only code IDs thus requiring applications obtain and hold structural metadata about the data set in order to display the content in human-readable form.
... ... @@ -331,7 +331,7 @@
331 331  1. //Data: //For the exchange of data. Unlike SDMX-ML, the structure of a SDMX-JSON data message is not specific to the DSDs of the data sets so schema validation will not check for compliance of the data with the DSDs.
332 332  1. //Metadata//: For the exchange of reference metadata sets.
333 333  
334 -== {{id name="_Toc56242"/}}5.3 SDMX-CSV ==
318 +== 5.3 SDMX-CSV ==
335 335  
336 336  SDMX-CSV is the CSV transmission format specification for exchanging data and reference metadata only.
337 337  
... ... @@ -342,7 +342,7 @@
342 342  1. //Data//: For the exchange of data. Like SDMX-JSON, SDMX-CSV can include both code IDs and labels which is helpful when using the data to create human readable charts and dashboards.
343 343  1. //Metadata//: For the exchange of reference metadata sets.
344 344  
345 -== {{id name="_Toc56243"/}}5.4 Formats and Messages Deprecated in Version 3.0 ==
329 +== 5.4 Formats and Messages Deprecated in Version 3.0 ==
346 346  
347 347  The following formats and messages have been deprecated in version 3.0 to simplify, modernise and rationalise the standard.
348 348  
... ... @@ -359,35 +359,35 @@
359 359  * SDMX-ML Query messages
360 360  * SDMX-ML Submit Structure Request messages
361 361  
362 -= {{id name="_Toc56244"/}}6 Dependencies on SDMX content-oriented guidelines =
346 += 6 Dependencies on SDMX content-oriented guidelines =
363 363  
364 364  The technical standards proposed here are designed so that they can be used in conjunction with other SDMX guidelines which are more closely tied to the content and semantics of statistical data exchange. The SDMX Information Model works equally well with any statistical concept, but to encourage interoperability, it is also necessary to standardize and harmonize the use of specific concepts and terminology. To achieve this goal, SDMX creates and maintains guidelines for cross-domain concepts, terminology, and structural definitions. There are three major parts to this effort.
365 365  
366 -== {{id name="_Toc56245"/}}6.1 Cross-Domain Concepts ==
350 +== 6.1 Cross-Domain Concepts ==
367 367  
368 368  The SDMX Cross-Domain Concepts is a content guideline concerning concepts which are used across statistical domains. This list is expected to grow and to be subject to revision as SDMX is used in a growing number of domains. The use of the SDMX Cross-Domain Concepts, where appropriate, provides a framework to further promote interoperability among organisations using the technical standards presented here. The harmonization of statistical concepts includes not only the definitions of the concepts, and their names, but also, where appropriate, their representation with standard code lists, and the role they play within data structure definitions and metadata structure definitions.
369 369  
370 370  The intent of this guideline is two-fold: to provide a core set of concepts which can be used to structure statistical data and metadata, to promote interoperability between systems (“structural metadata”, as described above); and to promote the exchange of metadata more widely, with a set of harmonized concept names and definitions for other types of metadata (“reference metadata”, as defined above.)
371 371  
372 -== {{id name="_Toc56246"/}}6.2 Metadata Common Vocabulary ==
356 +== 6.2 Metadata Common Vocabulary ==
373 373  
374 374  The Metadata Common Vocabulary is an SDMX guideline which provides definition of terms to be used for the comparison and mapping of terminology found in data structure definitions and in other aspects of statistical metadata management. Essentially, it provides ISOcompliant definitions for a wide range of statistical terms, which may be used directly, or against which other terminology systems may be mapped. This set of terms is inclusive of the terminology used within the SDMX Technical Standards.
375 375  
376 376  The MCV provides definitions for terms on which the SDMX Cross-Domain Metadata Concepts work is built.
377 377  
378 -== {{id name="_Toc56247"/}}6.3 Statistical Subject-Matter Domains ==
362 +== 6.3 Statistical Subject-Matter Domains ==
379 379  
380 380  The Statistical Subject-Matter Domains is a listing of the breadth of statistical information for the purposes of organizing widespread statistical exchange and categorization. It acts as a standard scheme against which the categorization schemes of various counterparties can be mapped, to facilitate interoperable data and metadata exchange. It serves another useful purpose, however, which is to allow an organization of corresponding “domain groups”, each of which could define standard data structure definitions, concepts, etc. within their domains. Such groups already exist within the international community. SDMX would use the Statistical Subject-Matter Domains list to facilitate the efforts of these groups to develop the kinds of content standards which could support the interoperation of SDMX-conformant technical systems within and across statistical domains. The organisation of the content of such schemes is supported in SDMX as a Category Scheme.
381 381  
382 382  SDMX Statistical Subject-Matter Domains will be listed and maintained by the SDMX Initiative and will be subject to adjustment.
383 383  
384 -== {{id name="_Toc56248"/}}6.4 SDMX Concept Roles ==
368 +== 6.4 SDMX Concept Roles ==
385 385  
386 386  These guidelines define the standard set of SDMX Concept Roles and their use. This set of standard SDMX Concepts are implemented as a cross-domain Concept Scheme that defines the set of concept roles and gives examples on concept role implementation in SDMX 2.0, 2.1 and 3.0. A concept role gives a particular context to a concept for easy and systematic interpretation by machine processing and visualization tools. For example, the concepts REPORTING_AREA and COUNTERPART_AREA are different concepts but they are both geographical characteristics, therefore they can be associated with the same concept role ID: "GEO". This allows visualization systems to interpret these concepts as geographical data in order to generate maps. The implementation of concept roles is different in versions 2.0 and 2.1/3.0 of the SDMX technical standard. Specifically for SDMX 3.0, this set of roles is considered a normative list that must be interpreted in the same way by all organisations.
387 387  
388 388  Additional roles may be provided via the standard roles’ mechanism in SDMX 3.0, i.e., via Concept Schemes; the semantics of these roles have to be agreed bilateraly in data exchanges. The Concept Roles are available as an SDMX Concept Scheme on the SDMX Global Registry.
389 389  
390 -= {{id name="_Toc56249"/}}7 Validation and Transformation Language =
374 += 7 Validation and Transformation Language =
391 391  
392 392  For many years the SDMX initiative has been fostering and supporting the development of a standard calculation language, called Validation and Transformation Language (VTL). A blueprint for defining calculations was already described in the original SDMX 2.1 specifications (package 13 of the Information Model - “Transformations and Expressions”). It was just a basic framework that required further developments to became operational in order to achieve a calculation language able to manipulate SDMX artefacts.
393 393  
SUZ.Methodology.Code.MethodologyClass[0]