Last modified by Helena on 2025/09/10 11:19

From version 8.2
edited by Helena
on 2025/05/14 13:39
Change comment: Update document after refactoring.
To version 7.2
edited by Helena
on 2025/05/14 13:28
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -SDMX STANDARDS1
1 +1 Overview
Parent
... ... @@ -1,1 +1,0 @@
1 -Methodology.WebHome
Content
... ... @@ -4,10 +4,9 @@
4 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
7 +|Revision|Date|Contents
8 +|DRAFT 1.0|May 2021|Draft release updated for SDMX 3.0 for public consultation
9 +|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"]])
27 + 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**;**
38 + 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  
... ... @@ -67,8 +67,7 @@
67 67  
68 68  == //2.1 Web Services API// ==
69 69  
70 -(% style="width:948.039px" %)
71 -|**REST API**|(% style="width:818px" %)(((
69 +|**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.
85 +|**SOAP API**|The SOAP API has been deprecated.
88 88  
89 89  == //2.2 Transmission Formats// ==
90 90  
89 +:
90 +
91 91  (((
92 -(% style="width:952.039px" %)
93 -|(% style="width:130px" %)**SDMX-ML**|(% style="width:820px" %)(((
92 +|**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
108 +* Changes to the way the structures are organised into
109 +
110 +‘collections’ within the message
111 +
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" %)(((
114 +|**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
120 +* Changes to the way the structures are organised into
121 +
122 +‘collections’ within the message
123 +
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.
126 +|**SDMX-EDI**|The EDI format for both structures and data has been deprecated.
127 +|**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 125  == //2.3 Information Model// ==
126 126  
132 +:
133 +
127 127  (((
128 -(% style="width:955.039px" %)
129 -|(% style="width:132px" %)**Data Structure Definition**|(% style="width:819px" %)(((
135 +|**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" %)(((
144 +|**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" %)(((
153 +|**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.
160 +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
161 +)))
162 +| |(((
163 +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" %)(((
167 +|**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" %)(((
176 +|**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//
... ... @@ -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
227 +* 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  
... ... @@ -499,7 +499,7 @@
499 499  
500 500  = 4 Versioning of Structural Metadata Artefacts =
501 501  
502 -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.
510 +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.
503 503  
504 504  Semantic version numbers are three digits:
505 505  
... ... @@ -581,12 +581,11 @@
581 581  
582 582  /data/dataflow/ESTAT/ICP?c[REF_AREA]=DE&c[ICP_ITEM]=sw:01&c[TIME_PERIOD]=ge:2015 Operators include:
583 583  
584 -(% style="width:531.039px" %)
585 -|(% style="width:151px" %)eq|(% style="width:378px" %)Equals
586 -|(% style="width:151px" %)ne|(% style="width:378px" %)Not equal to
587 -|(% style="width:151px" %)le|(% style="width:378px" %)Less than
588 -|(% style="width:151px" %)ge|(% style="width:378px" %)Greater than or equal to
589 -|(% style="width:151px" %)sw|(% style="width:378px" %)Starts with
592 +|eq|Equals
593 +|ne|Not equal to
594 +|le|Less than
595 +|ge|Greater than or equal to
596 +|sw|Starts with
590 590  
591 591  === Support for multiple keys ===
592 592  
... ... @@ -628,49 +628,47 @@
628 628  
629 629  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:
630 630  
631 -(% style="width:1102.04px" %)
632 -|(% style="width:321px" %)**Artefact type**|(% style="width:351px" %)**Version 2.1 Collection**|(% style="width:426px" %)**Version 3.0 Collection**
633 -|(% style="width:321px" %)AgencyScheme|(% style="width:351px" %)OrganisationSchemes|(% style="width:426px" %)AgencySchemes
634 -|(% style="width:321px" %)DataConsumerScheme|(% style="width:351px" %)OrganisationSchemes|(% style="width:426px" %)DataConsumerSchemes
635 -|(% style="width:321px" %)DataProviderScheme|(% style="width:351px" %)OrganisationSchemes|(% style="width:426px" %)DataProviderSchemes
636 -|(% style="width:321px" %)MetadataProviderScheme|(% style="width:351px" %)OrganisationSchemes|(% style="width:426px" %)MetadataProviderSchemes
637 -|(% style="width:321px" %)OrganisationUnitScheme|(% style="width:351px" %)OrganisationSchemes|(% style="width:426px" %)OrganisationUnitSchemes
638 -|(% style="width:321px" %)GeographicCodelist|(% style="width:351px" %)Codelists|(% style="width:426px" %)GeographicCodelists
639 -|(% style="width:321px" %)GeoGridCodelist|(% style="width:351px" %)Codelists|(% style="width:426px" %)GeoGridCodelists
640 -|(% style="width:321px" %)ConceptScheme|(% style="width:351px" %)Concepts|(% style="width:426px" %)ConceptSchemes
641 -|(% style="width:321px" %)ValueList|(% style="width:351px" %)Codelists|(% style="width:426px" %)ValueLists
642 -|(% style="width:321px" %)StructureMap|(% style="width:351px" %)StructureMappings|(% style="width:426px" %)StructureMaps
643 -|(% style="width:321px" %)RepresentationMap|(% style="width:351px" %)StructureMappings|(% style="width:426px" %)RepresentationMaps
644 -|(% style="width:321px" %)ConceptSchemeMap|(% style="width:351px" %)StructureMappings|(% style="width:426px" %)ConceptSchemeMaps
645 -|(% style="width:321px" %)CategorySchemeMap|(% style="width:351px" %)StructureMappings|(% style="width:426px" %)CategorySchemeMaps
646 -|(% style="width:321px" %)OrganisationSchemeMap|(% style="width:351px" %)StructureMappings|(% style="width:426px" %)OrganisationSchemeMaps
647 -|(% style="width:321px" %)ReportingTaxonomyMap|(% style="width:351px" %)StructureMappings|(% style="width:426px" %)ReportingTaxonomyMaps
648 -|(% style="width:321px" %)DataConstraint|(% style="width:351px" %)Constraints|(% style="width:426px" %)DataConstraints
649 -|(% style="width:321px" %)MetadataConstraint|(% style="width:351px" %)Constraints|(% style="width:426px" %)MetadataConstraints
650 -|(% style="width:321px" %)MetadataProvisionAgreement|(% style="width:351px" %)ProvisionAgreement|(% style="width:426px" %)MetadataProvisionAgreements
651 -|(% style="width:321px" %)CustomTypeScheme|(% style="width:351px" %)CustomTypes|(% style="width:426px" %)CustomTypeSchemes
652 -|(% style="width:321px" %)VtlMappingScheme|(% style="width:351px" %)VtlMappings|(% style="width:426px" %)VtlMappingSchemes
653 -|(% style="width:321px" %)NamePersonalisationScheme|(% style="width:351px" %)NamePersonalisations|(% style="width:426px" %)NamePersonalisationSchemes
654 -|(% style="width:321px" %)RulesetScheme|(% style="width:351px" %)Rulesets|(% style="width:426px" %)RulesetSchemes
655 -|(% style="width:321px" %)TransformationScheme|(% style="width:351px" %)Transformations|(% style="width:426px" %)TransformationSchemes
656 -|(% style="width:321px" %)UserDefinedOperatorScheme|(% style="width:351px" %)UserDefinedOperators|(% style="width:426px" %)UserDefinedOperatorSchemes
638 +|**Artefact type**|**Version 2.1 Collection**|**Version 3.0 Collection**
639 +|AgencyScheme|OrganisationSchemes|AgencySchemes
640 +|DataConsumerScheme|OrganisationSchemes|DataConsumerSchemes
641 +|DataProviderScheme|OrganisationSchemes|DataProviderSchemes
642 +|MetadataProviderScheme|OrganisationSchemes|MetadataProviderSchemes
643 +|OrganisationUnitScheme|OrganisationSchemes|OrganisationUnitSchemes
644 +|GeographicCodelist|Codelists|GeographicCodelists
645 +|GeoGridCodelist|Codelists|GeoGridCodelists
646 +|ConceptScheme|Concepts|ConceptSchemes
647 +|ValueList|Codelists|ValueLists
648 +|StructureMap|StructureMappings|StructureMaps
649 +|RepresentationMap|StructureMappings|RepresentationMaps
650 +|ConceptSchemeMap|StructureMappings|ConceptSchemeMaps
651 +|CategorySchemeMap|StructureMappings|CategorySchemeMaps
652 +|OrganisationSchemeMap|StructureMappings|OrganisationSchemeMaps
653 +|ReportingTaxonomyMap|StructureMappings|ReportingTaxonomyMaps
654 +|DataConstraint|Constraints|DataConstraints
655 +|MetadataConstraint|Constraints|MetadataConstraints
656 +|MetadataProvisionAgreement|ProvisionAgreement|MetadataProvisionAgreements
657 +|CustomTypeScheme|CustomTypes|CustomTypeSchemes
658 +|VtlMappingScheme|VtlMappings|VtlMappingSchemes
659 +|NamePersonalisationScheme|NamePersonalisations|NamePersonalisationSchemes
660 +|RulesetScheme|Rulesets|RulesetSchemes
661 +|TransformationScheme|Transformations|TransformationSchemes
662 +|UserDefinedOperatorScheme|UserDefinedOperators|UserDefinedOperatorSchemes
657 657  
658 658  No changes have been made to the way the following artefacts are organised in the structure message:
659 659  
660 -(% style="width:1106.04px" %)
661 -|(% style="width:326px" %)**Artefact type**|(% style="width:776px" %)**Collection**
662 -|(% style="width:326px" %)Dataflow|(% style="width:776px" %)Dataflows
663 -|(% style="width:326px" %)Metadataflow|(% style="width:776px" %)Metadataflows
664 -|(% style="width:326px" %)CategoryScheme|(% style="width:776px" %)CategorySchemes
665 -|(% style="width:326px" %)Categorisation|(% style="width:776px" %)Categorisations
666 -|(% style="width:326px" %)Codelist|(% style="width:776px" %)Codelists
667 -|(% style="width:326px" %)Hierarchy|(% style="width:776px" %)Hierarchies
668 -|(% style="width:326px" %)HierarchyAssociation|(% style="width:776px" %)HierarchyAssociations
669 -|(% style="width:326px" %)MetadataStructure|(% style="width:776px" %)MetadataStructures
670 -|(% style="width:326px" %)DataStructure|(% style="width:776px" %)DataStructures
671 -|(% style="width:326px" %)ReportingTaxonomy|(% style="width:776px" %)ReportingTaxonomies
672 -|(% style="width:326px" %)Process|(% style="width:776px" %)Processes
673 -|(% style="width:326px" %)ProvisionAgreement|(% style="width:776px" %)ProvisionAgreements
666 +|**Artefact type**|**Collection**
667 +|Dataflow|Dataflows
668 +|Metadataflow|Metadataflows
669 +|CategoryScheme|CategorySchemes
670 +|Categorisation|Categorisations
671 +|Codelist|Codelists
672 +|Hierarchy|Hierarchies
673 +|HierarchyAssociation|HierarchyAssociations
674 +|MetadataStructure|MetadataStructures
675 +|DataStructure|DataStructures
676 +|ReportingTaxonomy|ReportingTaxonomies
677 +|Process|Processes
678 +|ProvisionAgreement|ProvisionAgreements
674 674  
675 675  From version 3.0, collections can appear in any order within a structure message.
676 676