Skip to Content
Last modified by Helena on 2025/09/10 11:19
From version 13.2
edited by Helena
on 2025/05/14 15:01
Change comment: There is no comment for this version
To version 2.2
edited by Helena
on 2025/05/14 13:26
Change comment: Changed document title to [1 Overview].

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -SDMX STANDARDS
1 +1 Overview
Parent
... ... @@ -1,1 +1,0 @@
1 -Methodology.WebHome
Content
... ... @@ -1,13 +5,8 @@
1 -{{box title="**Contents**"}}
2 -{{toc/}}
3 -{{/box}}
4 -
5 5  **Revision History**
6 6  
7 -(% style="width:738.039px" %)
8 -|(% style="width:187px" %)Revision|(% style="width:157px" %)Date|(% style="width:390px" %)Contents
9 -|(% style="width:187px" %)DRAFT 1.0|(% style="width:157px" %)May 2021|(% style="width:390px" %)Draft release updated for SDMX 3.0 for public consultation
10 -|(% style="width:187px" %)1.0|(% style="width:157px" %)October 2021|(% style="width:390px" %)Public Release for SDMX 3.0
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
11 11  
12 12  = 1 Overview =
13 13  
... ... @@ -25,7 +25,7 @@
25 25  
26 26  **Versioning of Structural Metadata Artefacts**
27 27  
28 -* Adoption of the three-number semantic versioning standard for structural metadata artefacts ([[https:~~/~~/semver.org/>>https://semver.org/||rel="noopener noreferrer" target="_blank"]])
23 +• 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/]]
29 29  
30 30  **REST Web Services Application Programming Interface (API)**
31 31  
... ... @@ -36,7 +36,7 @@
36 36  
37 37  **SOAP Web Services API**
38 38  
39 -* The SOAP web services API has been deprecated with version 3.0 standardising on REST**;**
34 +• The SOAP web services API has been deprecated with version 3.0 standardising on REST** **
40 40  
41 41  **XML, JSON, CSV and EDI Transmission formats**
42 42  
... ... @@ -65,10 +65,9 @@
65 65  
66 66  Version 3.0 introduces breaking changes into the web services API, transmission formats and information model. A summary is given in the table below.
67 67  
68 -== 2.1 Web Services API ==
63 +== //2.1 Web Services API// ==
69 69  
70 -(% style="width:948.039px" %)
71 -|**REST API**|(% style="width:818px" %)(((
65 +|**REST API**|(((
72 72  The REST API is not backwardly compatible due to modifications to the URLs and query parameters resulting in breaking changes in four of the five main resources:
73 73  
74 74  * Structure queries
... ... @@ -84,13 +84,14 @@
84 84  
85 85  Implementors are also recommended to version their API services providing users with an explicit choice of which version to use.
86 86  )))
87 -|**SOAP API**|(% style="width:818px" %)The SOAP API has been deprecated.
81 +|**SOAP API**|The SOAP API has been deprecated.
88 88  
89 -== 2.2 Transmission Formats ==
83 +== //2.2 Transmission Formats// ==
90 90  
85 +:
86 +
91 91  (((
92 -(% style="width:952.039px" %)
93 -|(% style="width:130px" %)**SDMX-ML**|(% style="width:820px" %)(((
88 +|**SDMX-ML**|(((
94 94  The following legacy XML data messages have been deprecated:
95 95  
96 96  SDMX-ML 1.0/2.0 Generic (time-series) data message
... ... @@ -106,27 +106,34 @@
106 106  The SDMX-ML structure message is not backwardly compatible primarily due to:
107 107  
108 108  * Changes to the information model
109 -* Changes to the way the structures are organised into ‘collections’ within the message
104 +* Changes to the way the structures are organised into
105 +
106 +‘collections’ within the message
107 +
110 110  * Deprecation of the Agency, ID, Version option for referencing of structures in messages
111 111  )))
112 -|(% style="width:130px" %)**SDMX-JSON**|(% style="width:820px" %)(((
110 +|**SDMX-JSON**|(((
113 113  The JSON data message is not backwardly compatible with version 2.1 primarily due to changes needed to support the improved REST API data queries, in particular the ability to retrieve in one operation data from multiple datasets with potentially different Data Structure Definitions.
114 114  
115 115  The JSON structure message is not backwardly compatible primarily due to:
116 116  
117 117  * Changes to the information model
118 -* Changes to the way the structures are organised into ‘collections’ within the message
116 +* Changes to the way the structures are organised into
117 +
118 +‘collections’ within the message
119 +
119 119  * Deprecation of the Agency, ID, Version option for referencing of structures in messages
120 120  )))
121 -|(% style="width:130px" %)**SDMX-EDI**|(% style="width:820px" %)The EDI format for both structures and data has been deprecated.
122 -|(% style="width:130px" %)**SDMX-CSV**|(% style="width:820px" %)The CSV data and reference metadata messages are not backwardly compatible with those under version 2.1 due to changes to the structure of the messages needed to support new features such as the improved REST API data queries.
122 +|**SDMX-EDI**|The EDI format for both structures and data has been deprecated.
123 +|**SDMX-CSV**|The CSV data and reference metadata messages are not backwardly compatible with those under version 2.1 due to changes to the structure of the messages needed to support new features such as the improved REST API data queries.**     **
123 123  )))
124 124  
125 -== 2.3 Information Model ==
126 +== //2.3 Information Model// ==
126 126  
128 +:
129 +
127 127  (((
128 -(% style="width:955.039px" %)
129 -|(% style="width:132px" %)**Data Structure Definition**|(% style="width:819px" %)(((
131 +|**Data Structure Definition**|(((
130 130  The version 3.0 Data Structure Definition (DSD) model is not directly backwardly compatible with 2.1 primarily due to the deprecation of the special MeasureDimension.
131 131  
132 132  //Conversion guidance for implementors//
... ... @@ -135,7 +135,7 @@
135 135  
136 136  Version 3.0 DSDs cannot be reliably converted to the 2.1 model due to the introduction of new features such as multiple measures and value arrays for measures and attributes.
137 137  )))
138 -|(% style="width:132px" %)**Structure mapping model**|(% style="width:819px" %)(((
140 +|**Structure mapping model**|(((
139 139  The structure mapping model has changed significantly in version 3.0 with deprecation of the Structure Set maintainable artefact and introduction of five new ones: Representation Map and four variants of item scheme map.
140 140  
141 141  //Conversion guidance for implementors//
... ... @@ -144,7 +144,7 @@
144 144  
145 145  Conversion from the version 3.0 structure mapping model to 2.1 is generally possible. However, when attempting to convert mapping rules from 2.1 to 3.0 and back to 2.1, the resulting Structure Set will not be precisely the same as the original. In converting to version 3.0, the system must generate IDs for each of the new maintainable artefacts, but details of the original Structure Set artefacts are lost.
146 146  )))
147 -|(% style="width:132px" %)**Reference metadata model**|(% style="width:819px" %)(((
149 +|**Reference metadata model**|(((
148 148  The reference metadata model has changed in version 3.0 with modifications to the role of the Data Structure Definition, Metadata Structure Definition and Metadataflow artefacts. Metadata Provision Agreement and Metadata Provider Scheme have been added. Metadatasets are now identifiable.
149 149  
150 150  Version 2.1 reference metadata models are not valid in version 3.0.
... ... @@ -151,11 +151,14 @@
151 151  
152 152  //Conversion guidance for implementors//
153 153  
154 -A version 2.1 Metadata Structure Definition can be converted to the version 3.0 model under some circumstances, but target information is either lost or has to be translated into a metadataflow. Further, conversion of a Data Structure Definition for collecting reference metadata against a dataset would need to make changes to the dataset’s Data Structure Definition. As the Data Structure Definition may not actually be specified, judgement would need to be taken, perhaps determining the most likely candidate by examining which already have metadata reported against their datasets. A 2.1 metadata report could be converted to a version 3.0 Metadataset if it is attached to a structure, but requires a Metadata Provision Agreement which would need to be created if not already in existence.
156 +A version 2.1 Metadata Structure Definition can be converted to the version 3.0 model under some circumstances, but target information is either lost or has to be translated into a metadataflow. Further, conversion of a Data Structure Definition for collecting reference metadata against a dataset would need to make changes to the dataset’s Data Structure Definition. As the Data Structure Definition may not actually be specified, judgement would need to be taken, perhaps determining the most likely candidate by examining which
157 +)))
158 +||(((
159 +already have metadata reported against their datasets. A 2.1 metadata report could be converted to a version 3.0 Metadataset if it is attached to a structure, but requires a Metadata Provision Agreement which would need to be created if not already in existence.
155 155  
156 156  Conversion from the version 3.0 model to version 2.1 cannot be performed reliably. The process would need target information to be derived from analysis of the Metadataflows and Metadata Provision Agreements. Depending on the complexity it may not be possible to express that information in a version 2.1 Data Structure Definition.
157 157  )))
158 -|(% style="width:132px" %)**Constraint model**|(% style="width:819px" %)(((
163 +|**Constraint model**|(((
159 159  The version 2.1 Content Constraint artefact has been deprecated in version 3.0 and replaced by the Data Constraint for data, and the Metadata Constraint for reference metadata.
160 160  
161 161  //Conversion guidance for implementors//
... ... @@ -164,7 +164,7 @@
164 164  
165 165  Conversion from 3.0 to 2.1 presents challenges where wildcards have been used, in those cases requiring expansion of the wildcard into explicit values.
166 166  )))
167 -|(% style="width:132px" %)**Hierarchical codelist structures**|(% style="width:819px" %)(((
172 +|**Hierarchical codelist structures**|(((
168 168  The version 2.1 Hierarchical Codelist artefact has been deprecated in version 3.0 and replaced by two new artefacts, Hierarchy and Hierarchy Association.
169 169  
170 170  //Conversion guidance for implementors//
... ... @@ -177,7 +177,7 @@
177 177  
178 178  = 3 Information Model =
179 179  
180 -== 3.1 Version 3.0 Information Model ==
185 +== //3.1 Version 3.0 Information Model// ==
181 181  
182 182  [[image:SDMX 3-0-0 Major Changes FINAL-1.0_en_6fc573fe.png||height="404" width="718"]]
183 183  
... ... @@ -187,7 +187,7 @@
187 187  
188 188  A number of ancillary structures including organisation schemes, process and reporting taxonomy are unchanged and have not been shown. Similarly, Organisation Scheme Map and Reporting Taxonomy Map have been omitted for simplicity. A schematic of the 2.1 model is given in Appendix A for comparison purposes.
189 189  
190 -== 3.2 Key Changes from Version 2.1 ==
195 +== //3.2 Key Changes from Version 2.1// ==
191 191  
192 192  New Maintainable Artefacts
193 193  
... ... @@ -215,8 +215,7 @@
215 215  Removed Maintainable Artefacts
216 216  
217 217  * Structure Set – replaced by Structure Map and the four item scheme maps
218 -* Hierarchical Codelist – replaced by Hierarchy and Hierarchy Association
219 -* Constraint – replaced by Data Constraint and Metadata Constraint
223 +* Hierarchical Codelist – replaced by Hierarchy and Hierarchy Association • Constraint – replaced by Data Constraint and Metadata Constraint
220 220  
221 221  Changed Maintainable Artefacts
222 222  
... ... @@ -230,7 +230,7 @@
230 230  
231 231  * GeospatialInformation – a string type where the value is an expression defining a set of geographical features using a purpose-designed syntax
232 232  
233 -== 3.3 Areas Unchanged from Version 2.1 ==
237 +== //3.3 Areas Unchanged from Version 2.1// ==
234 234  
235 235  The following areas of the information model are unchanged from version 2.1:
236 236  
... ... @@ -243,7 +243,7 @@
243 243  * Reporting taxonomy
244 244  * Process
245 245  
246 -== 3.4 Reference Metadata ==
250 +== //3.4 Reference Metadata// ==
247 247  
248 248  Reference metadata has been substantially re-designed for version 3.0 to simplify the model and better support practical use cases.
249 249  
... ... @@ -271,45 +271,84 @@
271 271  * TITLE – a multi-lingual data attribute
272 272  * SOURCE_AGENCY – a multi-value data attribute
273 273  
274 -> <Obs xsi:type="dsd:ObsType" OBS_VALUE="112" OBS_STAUS=”A” TIME_PERIOD="2010-09">
275 -> <!—- complex multi-value and multi-lingual data attributes ~-~->
276 -> <Comp id="TITLE" xsi:type="ns1:TITLE_ATTRIBUTE">
277 -> <Value>
278 -> <common:Text xml:lang="en">Some English Text</common:Text>
279 -> <common:Text xml:lang="fr">Quelques textes en anglais</common:Text>
280 -> </Value>
281 -> </Comp>
282 -> <Comp id="SOURCE_AGENCY" xsi:type="ns1:SOURCE_AGENCY_ATTRIBUTE">
283 -> <Value>4F0</Value>
284 -> <Value>4D0</Value>
285 -> <Value>CZ2</Value>
286 -> </Comp>
278 +<Obs xsi:type="dsd:ObsType" OBS_VALUE="112" OBS_STAUS=”A” TIME_PERIOD="2010-09">
279 +
280 +<!—- complex multi-value and multi-lingual data attributes ~-~->
281 +
282 +<Comp id="TITLE" xsi:type="ns1:TITLE_ATTRIBUTE">
283 +
284 +<Value>
285 +
286 +<common:Text xml:lang="en">Some English Text</common:Text>
287 +
288 +<common:Text xml:lang="fr">Quelques textes en anglais</common:Text>
289 +
290 +</Value>
291 +
292 +</Comp>
293 +
294 +<Comp id="SOURCE_AGENCY" xsi:type="ns1:SOURCE_AGENCY_ATTRIBUTE">
295 +
296 +<Value>4F0</Value>
297 +
298 +<Value>4D0</Value>
299 +
300 +<Value>CZ2</Value>
301 +
302 +</Comp>
303 +
287 287  <!—- metadata attributes are reported like in metadata messages ~-~->
305 +
288 288  <Metadata>
307 +
289 289  <Attribute id="COLLECTION">
309 +
290 290  <Attribute id="METHOD">
311 +
291 291  <Text lang="en">AAA</Text>
313 +
292 292  </Attribute>
315 +
293 293  </Attribute>
317 +
294 294  <Attribute id="CONTACT">
319 +
295 295  <Value>CONTACT 1</Value>
321 +
296 296  <Attribute id="NAME">
323 +
297 297  <Value>Contact 1 Name 1</Value>
325 +
298 298  </Attribute>
327 +
299 299  <Attribute id="NAME">
329 +
300 300  <Value>Contact 1 Name 2</Value>
331 +
301 301  </Attribute>
333 +
302 302  </Attribute>
335 +
303 303  <Attribute id="CONTACT">
337 +
304 304  <Value>CONTACT 2</Value>
339 +
305 305  <Attribute id="NAME">
341 +
306 306  <Value>Contact 2 Name 1</Value>
343 +
307 307  </Attribute>
345 +
308 308  <Attribute id="NAME">
347 +
309 309  <Value>Contact 2 Name 2</Value>
349 +
310 310  </Attribute>
351 +
311 311  </Attribute>
353 +
312 312  </Metadata>
355 +
313 313  </Obs>
314 314  
315 315  === New - Metadata Provision Agreement ===
... ... @@ -324,7 +324,7 @@
324 324  
325 325  A Metadataset now has mandatory identification information, (owner id, id, version) enabling metadata providers to uniquely identify their reports for create, update or delete maintenance operations.
326 326  
327 -== 3.5 Microdata Exchange ==
370 +== //3.5 Microdata Exchange// ==
328 328  
329 329  Several changes have been made the Data Structure Definition to support microdata use cases in addition to aggregated time series.
330 330  
... ... @@ -337,18 +337,31 @@
337 337  MeasureDimension behaviour as illustrated in the SDMX-ML example below:
338 338  
339 339  <str:MeasureList id=”MeasureDescriptor”>
383 +
340 340  <str:Measure id=”OBS_VALUE” minOccurs=”1” maxOccurs=”1” usage=”mandatory” > <str:ConceptIdentity>
385 +
341 341  <Ref id=”OBS_VALUE” maintainableParentID=”CONCEPTS” agencyID=”SDMX” maintainableParentVersion=”1.0.0” />
387 +
342 342  </str:ConceptIdentity>
389 +
343 343  <str:LocalRepresentation>
391 +
344 344  <str:TextFormat textType=”String” isMultiLingual=”true” />
393 +
345 345  </str:LocalRepresentation>
395 +
346 346  <str:ConceptRole>
397 +
347 347  <Ref id=”MEASURE” maintainableParentID=”SDMX_CONCEPT_ROLES” agencyID=”SDMX” maintainableParentVersion=”1.0.0” />
399 +
348 348  </str:ConceptRole>
401 +
349 349  </str:Measure>
403 +
350 350  ...
405 +
351 351  <str:Measure>
407 +
352 352  </str:MeasureList>
353 353  
354 354  === Multi-value measures and attributes ===
... ... @@ -369,7 +369,7 @@
369 369  
370 370  That allows ValueItems (the equivalent to Code) to contain symbols like ‘¥’ and ‘€’, but 208 also means they are not identifiable.
371 371  
372 -== 3.6 Geospatial Data Exchange ==
428 +== //3.6 Geospatial Data Exchange// ==
373 373  
374 374  The version 3.0 model has been extended to provide explicit support for geospatial data.
375 375  
... ... @@ -384,13 +384,13 @@
384 384  * GeographicCodelist – each item includes an element to represent a specific Geo Feature Set which is described using the same expression syntax as for GeospatialInformation type.
385 385  * GeoGridCodelist – A code list defining a geographical grid composed of cells representing regular squared portions of the Earth. Each item references a cell within the grid.
386 386  
387 -== 3.7 Structure Mapping ==
443 +=== //3.7 Structure Mapping// ===
388 388  
389 389  The Structure Set in version 2.1 is a container for many mapping structures including Data Structure Map, Codelist Map and Concept Map. For version 3.0 the Structure Set artefact has been deprecated and replaced with a number of new maintainables giving better flexibility and reusability, specifically: Structure Map, Concept Scheme Map, Representation Map, Reporting Taxonomy Map, Category Scheme Map and Organisation Scheme Map.
390 390  
391 391  The version 2.1 Codelist Map been replaced with Representation Map which allows mappings to be defined between any combination of Code Lists, Value Lists and noncoded representations such as text strings and numbers.
392 392  
393 -=== Many-to-many source and target components ===
449 +==== Many-to-many source and target components ====
394 394  
395 395  Structure mapping rules may be defined with both multiple source components and multiple target components in contrast to version 2.1 where only one source and target was allowed. That supports many-to-many (n-n) mapping use cases where the output of a mapping rule may be dependent on the combination of a number of input components. For instance:
396 396  
... ... @@ -404,19 +404,19 @@
404 404  
405 405  The Structure Map may now define input or output components which have a fixed value.
406 406  
407 -=== Time representations mapping ===
463 +==== Time representations mapping ====
408 408  
409 409  Non SDMX time representations may now be described in a Structure Map, allowing them to be mapped into SDMX time formats.
410 410  
411 -=== Regular expression and substring mappings ===
467 +==== Regular expression and substring mappings ====
412 412  
413 413  All item maps allow the use of regular expressions and substrings to match source values, specifically: Concept Scheme Map, Reporting Taxonomy Map, Category Scheme Map and Organisation Scheme Map.
414 414  
415 -=== Item maps validity period ===
471 +==== Item maps validity period ====
416 416  
417 417  Item maps may further define the period for which the mapping is valid, meaning the mapping rule will only be applied if the row of information being mapped is within the period.
418 418  
419 -== 3.8 Constraints ==
475 +=== //3.8 Constraints// ===
420 420  
421 421  Constraints in version 3.0 are modelled using two separate artefacts which replace the version 2.1 content constraint:
422 422  
... ... @@ -431,23 +431,23 @@
431 431  
432 432  Attachment constraints have been deprecated due to a lack of use cases.
433 433  
434 -== 3.9 Code List Extension ==
490 +=== //3.9 Code List Extension// ===
435 435  
436 436  In addition to the two new specialised geospatial forms, the option has been added to define a code list as an extension of, or by inheriting codes from, other lists. An optional prefix can be added to inherited codes to disambiguate duplicates.
437 437  
438 438  This feature allows new code lists to be easily derived from existing lists without the need to make and manually maintain copies. When querying for extended code list structures using the REST API, the option has been added to retrieve either the definition or the materialised list. Traditional literal lists of codes continue to be supported.
439 439  
440 -== 3.10 Discriminated Union of Code Lists ==
496 +=== //3.10 Discriminated Union of Code Lists// ===
441 441  
442 442  Combining code list extension with wildcarded constraints solves the discriminated union of code lists problem where a classification or breakdown has multiple “variants” which are all valid but mutually exclusive. A common example is economic activity where several alternative classification schemes are in use including ISIC revisions 1 to 4 and NACE as used in the European Community.
443 443  
444 -== 3.11 Code Hierarchies ==
500 +=== //3.11 Code Hierarchies// ===
445 445  
446 446  Code hierarchies allow the definition of complex hierarchies of codes from potentially multiple lists for data discovery purposes. Hierarchical Codelist has been deprecated and replaced by two new artefacts: Hierarchy – the actual hierarchy of codes, and Hierarchy Association links hierarchies directly to any other identifiable object, a capability missing 312 from the version 2.1 model. Further, the linkage can be within a particular context, for instance linking a hierarchy to a dimension within the context of a specific Dataflow (dimension REF_AREA in the context of the ECB:EXR Dataflow).
447 447  
448 448  = 4 Versioning of Structural Metadata Artefacts =
449 449  
450 -Version 3.0 adopts semantic versioning principles for versioning of metadata artefacts following the rules set out at __[[https:~~/~~/semver.org>>https://semver.org]] __However, this is not mandatory, and organisations may continue to use the pre-existing two-digit versioning strategy, or not to version artefacts by omitting the //version// property. The version number no longer defaults to 1.0 if not explicitly set.
506 +Version 3.0 adopts semantic versioning principles for versioning of metadata artefacts following the rules set out at [[__https:~~/~~/semver.org__>>url:https://semver.org/]][[.>>url:https://semver.org/]] However, this is not mandatory, and organisations may continue to use the pre-existing two-digit versioning strategy, or not to version artefacts by omitting the //version// property. The version number no longer defaults to 1.0 if not explicitly set.
451 451  
452 452  Semantic version numbers are three digits:
453 453  
... ... @@ -489,7 +489,7 @@
489 489  
490 490  = 5 REST Web Services API =
491 491  
492 -== 5.1 Simplified list of resources ==
548 +== //5.1 Simplified list of resources// ==
493 493  
494 494  The version 3.0 REST API has just five main resources:
495 495  
... ... @@ -503,7 +503,7 @@
503 503  
504 504  This and changes in the URLs and query parameters on the data, availability and metadata resources means that, with the exception of schema queries, the version 3.0 API is not backwardly compatible.
505 505  
506 -== 5.2 Improved data queries ==
562 +== //5.2 Improved data queries// ==
507 507  
508 508  Data queries have been changed to provide more granular selections from contexts wider than just a Dataflow.
509 509  
... ... @@ -529,12 +529,11 @@
529 529  
530 530  /data/dataflow/ESTAT/ICP?c[REF_AREA]=DE&c[ICP_ITEM]=sw:01&c[TIME_PERIOD]=ge:2015 Operators include:
531 531  
532 -(% style="width:531.039px" %)
533 -|(% style="width:151px" %)eq|(% style="width:378px" %)Equals
534 -|(% style="width:151px" %)ne|(% style="width:378px" %)Not equal to
535 -|(% style="width:151px" %)le|(% style="width:378px" %)Less than
536 -|(% style="width:151px" %)ge|(% style="width:378px" %)Greater than or equal to
537 -|(% style="width:151px" %)sw|(% style="width:378px" %)Starts with
588 +|eq|Equals
589 +|ne|Not equal to
590 +|le|Less than
591 +|ge|Greater than or equal to
592 +|sw|Starts with
538 538  
539 539  === Support for multiple keys ===
540 540  
... ... @@ -542,7 +542,7 @@
542 542  
543 543  /data/dataflow/ESTAT/ICP/1.0.0/M…A.ANR,M…A.INX,M…B.CTG
544 544  
545 -== 5.3 Improved reference metadata queries ==
600 +== //5.3 Improved reference metadata queries// ==
546 546  
547 547  Reference metadata queries have been improved with a number of new options to retrieve metadata reports.
548 548  
... ... @@ -558,7 +558,7 @@
558 558  
559 559  /metadata/structure/datastructure/BIS/BIS_CBS/1.0
560 560  
561 -== 5.4 Structural metadata maintenance ==
616 +== //5.4 Structural metadata maintenance// ==
562 562  
563 563  Support has been added for maintenance of structural metadata.
564 564  
... ... @@ -566,7 +566,7 @@
566 566  
567 567  = 6 XML, JSON, CSV and EDI Transmission formats =
568 568  
569 -== 6.1 SDMX-ML ==
624 +== //6.1 SDMX-ML// ==
570 570  
571 571  The SDMX-ML XML messages have been modified and updated for version 3.0. While they broadly follow the same principles, there have been significant changes which break backward compatibility.
572 572  
... ... @@ -576,49 +576,47 @@
576 576  
577 577  Additionally, the way the individual artefacts are organised into ‘collections’ within the message has been significantly revised with a simpler flat structure adopted as set out in the following table:
578 578  
579 -(% style="width:1102.04px" %)
580 -|(% style="width:321px" %)**Artefact type**|(% style="width:351px" %)**Version 2.1 Collection**|(% style="width:426px" %)**Version 3.0 Collection**
581 -|(% style="width:321px" %)AgencyScheme|(% style="width:351px" %)OrganisationSchemes|(% style="width:426px" %)AgencySchemes
582 -|(% style="width:321px" %)DataConsumerScheme|(% style="width:351px" %)OrganisationSchemes|(% style="width:426px" %)DataConsumerSchemes
583 -|(% style="width:321px" %)DataProviderScheme|(% style="width:351px" %)OrganisationSchemes|(% style="width:426px" %)DataProviderSchemes
584 -|(% style="width:321px" %)MetadataProviderScheme|(% style="width:351px" %)OrganisationSchemes|(% style="width:426px" %)MetadataProviderSchemes
585 -|(% style="width:321px" %)OrganisationUnitScheme|(% style="width:351px" %)OrganisationSchemes|(% style="width:426px" %)OrganisationUnitSchemes
586 -|(% style="width:321px" %)GeographicCodelist|(% style="width:351px" %)Codelists|(% style="width:426px" %)GeographicCodelists
587 -|(% style="width:321px" %)GeoGridCodelist|(% style="width:351px" %)Codelists|(% style="width:426px" %)GeoGridCodelists
588 -|(% style="width:321px" %)ConceptScheme|(% style="width:351px" %)Concepts|(% style="width:426px" %)ConceptSchemes
589 -|(% style="width:321px" %)ValueList|(% style="width:351px" %)Codelists|(% style="width:426px" %)ValueLists
590 -|(% style="width:321px" %)StructureMap|(% style="width:351px" %)StructureMappings|(% style="width:426px" %)StructureMaps
591 -|(% style="width:321px" %)RepresentationMap|(% style="width:351px" %)StructureMappings|(% style="width:426px" %)RepresentationMaps
592 -|(% style="width:321px" %)ConceptSchemeMap|(% style="width:351px" %)StructureMappings|(% style="width:426px" %)ConceptSchemeMaps
593 -|(% style="width:321px" %)CategorySchemeMap|(% style="width:351px" %)StructureMappings|(% style="width:426px" %)CategorySchemeMaps
594 -|(% style="width:321px" %)OrganisationSchemeMap|(% style="width:351px" %)StructureMappings|(% style="width:426px" %)OrganisationSchemeMaps
595 -|(% style="width:321px" %)ReportingTaxonomyMap|(% style="width:351px" %)StructureMappings|(% style="width:426px" %)ReportingTaxonomyMaps
596 -|(% style="width:321px" %)DataConstraint|(% style="width:351px" %)Constraints|(% style="width:426px" %)DataConstraints
597 -|(% style="width:321px" %)MetadataConstraint|(% style="width:351px" %)Constraints|(% style="width:426px" %)MetadataConstraints
598 -|(% style="width:321px" %)MetadataProvisionAgreement|(% style="width:351px" %)ProvisionAgreement|(% style="width:426px" %)MetadataProvisionAgreements
599 -|(% style="width:321px" %)CustomTypeScheme|(% style="width:351px" %)CustomTypes|(% style="width:426px" %)CustomTypeSchemes
600 -|(% style="width:321px" %)VtlMappingScheme|(% style="width:351px" %)VtlMappings|(% style="width:426px" %)VtlMappingSchemes
601 -|(% style="width:321px" %)NamePersonalisationScheme|(% style="width:351px" %)NamePersonalisations|(% style="width:426px" %)NamePersonalisationSchemes
602 -|(% style="width:321px" %)RulesetScheme|(% style="width:351px" %)Rulesets|(% style="width:426px" %)RulesetSchemes
603 -|(% style="width:321px" %)TransformationScheme|(% style="width:351px" %)Transformations|(% style="width:426px" %)TransformationSchemes
604 -|(% style="width:321px" %)UserDefinedOperatorScheme|(% style="width:351px" %)UserDefinedOperators|(% style="width:426px" %)UserDefinedOperatorSchemes
634 +|**Artefact type**|**Version 2.1 Collection**|**Version 3.0 Collection**
635 +|AgencyScheme|OrganisationSchemes|AgencySchemes
636 +|DataConsumerScheme|OrganisationSchemes|DataConsumerSchemes
637 +|DataProviderScheme|OrganisationSchemes|DataProviderSchemes
638 +|MetadataProviderScheme|OrganisationSchemes|MetadataProviderSchemes
639 +|OrganisationUnitScheme|OrganisationSchemes|OrganisationUnitSchemes
640 +|GeographicCodelist|Codelists|GeographicCodelists
641 +|GeoGridCodelist|Codelists|GeoGridCodelists
642 +|ConceptScheme|Concepts|ConceptSchemes
643 +|ValueList|Codelists|ValueLists
644 +|StructureMap|StructureMappings|StructureMaps
645 +|RepresentationMap|StructureMappings|RepresentationMaps
646 +|ConceptSchemeMap|StructureMappings|ConceptSchemeMaps
647 +|CategorySchemeMap|StructureMappings|CategorySchemeMaps
648 +|OrganisationSchemeMap|StructureMappings|OrganisationSchemeMaps
649 +|ReportingTaxonomyMap|StructureMappings|ReportingTaxonomyMaps
650 +|DataConstraint|Constraints|DataConstraints
651 +|MetadataConstraint|Constraints|MetadataConstraints
652 +|MetadataProvisionAgreement|ProvisionAgreement|MetadataProvisionAgreements
653 +|CustomTypeScheme|CustomTypes|CustomTypeSchemes
654 +|VtlMappingScheme|VtlMappings|VtlMappingSchemes
655 +|NamePersonalisationScheme|NamePersonalisations|NamePersonalisationSchemes
656 +|RulesetScheme|Rulesets|RulesetSchemes
657 +|TransformationScheme|Transformations|TransformationSchemes
658 +|UserDefinedOperatorScheme|UserDefinedOperators|UserDefinedOperatorSchemes
605 605  
606 606  No changes have been made to the way the following artefacts are organised in the structure message:
607 607  
608 -(% style="width:1106.04px" %)
609 -|(% style="width:326px" %)**Artefact type**|(% style="width:776px" %)**Collection**
610 -|(% style="width:326px" %)Dataflow|(% style="width:776px" %)Dataflows
611 -|(% style="width:326px" %)Metadataflow|(% style="width:776px" %)Metadataflows
612 -|(% style="width:326px" %)CategoryScheme|(% style="width:776px" %)CategorySchemes
613 -|(% style="width:326px" %)Categorisation|(% style="width:776px" %)Categorisations
614 -|(% style="width:326px" %)Codelist|(% style="width:776px" %)Codelists
615 -|(% style="width:326px" %)Hierarchy|(% style="width:776px" %)Hierarchies
616 -|(% style="width:326px" %)HierarchyAssociation|(% style="width:776px" %)HierarchyAssociations
617 -|(% style="width:326px" %)MetadataStructure|(% style="width:776px" %)MetadataStructures
618 -|(% style="width:326px" %)DataStructure|(% style="width:776px" %)DataStructures
619 -|(% style="width:326px" %)ReportingTaxonomy|(% style="width:776px" %)ReportingTaxonomies
620 -|(% style="width:326px" %)Process|(% style="width:776px" %)Processes
621 -|(% style="width:326px" %)ProvisionAgreement|(% style="width:776px" %)ProvisionAgreements
662 +|**Artefact type**|**Collection**
663 +|Dataflow|Dataflows
664 +|Metadataflow|Metadataflows
665 +|CategoryScheme|CategorySchemes
666 +|Categorisation|Categorisations
667 +|Codelist|Codelists
668 +|Hierarchy|Hierarchies
669 +|HierarchyAssociation|HierarchyAssociations
670 +|MetadataStructure|MetadataStructures
671 +|DataStructure|DataStructures
672 +|ReportingTaxonomy|ReportingTaxonomies
673 +|Process|Processes
674 +|ProvisionAgreement|ProvisionAgreements
622 622  
623 623  From version 3.0, collections can appear in any order within a structure message.
624 624  
... ... @@ -652,7 +652,7 @@
652 652  
653 653  The option to reference structures using Agency, ID and Version has been removed. From SDMX version 3.0 URN is used for all referencing purposes with the exception of local references such as where groups reference dimensions within a DSD.
654 654  
655 -== 6.2 SDMX-JSON ==
708 +== //6.2 SDMX-JSON// ==
656 656  
657 657  Like SDMX-ML, the SDMX-JSON messages have been significantly modified and updated for version 3.0. They are not backwardly compatible with version 2.1.
658 658  
... ... @@ -672,7 +672,7 @@
672 672  
673 673  As for SDMX-ML, the option to reference structures using Agency, ID and Version has been removed with URN used for all non-local referencing purposes.
674 674  
675 -== 6.3 SDMX-CSV ==
728 +== //6.3 SDMX-CSV// ==
676 676  
677 677  CSV in SDMX is used transmission of data and reference metadata only.
678 678  
... ... @@ -690,7 +690,7 @@
690 690  
691 691  The SDMX-CSV metadata message is new for version 3.0 and, like the SDMX-ML and SDMX-JSON equivalents, is used for the transmission reference metadata sets.
692 692  
693 -=== 6.4 EDI deprecation ===
746 +=== //6.4 EDI deprecation// ===
694 694  
695 695  The EDI format for transmission of both structures and data has been deprecated. Version 3.0 is therefore not backwardly compatible with legacy EDI messages.
696 696  
SDMX 3-0-0 Major Changes FINAL-1.0_en_5f21cdf9.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -103.2 KB
Content
SDMX 3-0-0 Major Changes FINAL-1.0_en_6fc573fe.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -148.8 KB
Content
SDMX 3-0-0 Major Changes FINAL-1.0_en_ad5f5c97.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -22.0 KB
Content
SDMX 3-0-0 Major Changes FINAL-1.0_en_f2695ed5.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -5.7 KB
Content
SUZ.Methodology.Code.MethodologyClass[0]