Changes for page SDMX 3.0 Standards. Summary of Major Changes and New Functionality
Last modified by Helena on 2025/09/10 11:19
Summary
-
Page properties (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -1,9 +1,13 @@ 1 -{{box title="**Contents**"}}{{toc/}}{{/box}} 1 +{{box title="**Contents**"}} 2 +{{toc/}} 3 +{{/box}} 4 + 2 2 **Revision History** 3 3 4 -|Revision|Date|Contents 5 -|DRAFT 1.0|May 2021|Draft release updated for SDMX 3.0 for public consultation 6 -|1.0|October 2021|Public Release for SDMX 3.0 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 7 8 8 = 1 Overview = 9 9 ... ... @@ -21,7 +21,7 @@ 21 21 22 22 **Versioning of Structural Metadata Artefacts** 23 23 24 - •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/]]28 +* Adoption of the three-number semantic versioning standard for structural metadata artefacts ([[https:~~/~~/semver.org/>>https://semver.org/||rel="noopener noreferrer" target="_blank"]]) 25 25 26 26 **REST Web Services Application Programming Interface (API)** 27 27 ... ... @@ -32,7 +32,7 @@ 32 32 33 33 **SOAP Web Services API** 34 34 35 - •The SOAP web services API has been deprecated with version 3.0 standardising on REST** **39 +* The SOAP web services API has been deprecated with version 3.0 standardising on REST**;** 36 36 37 37 **XML, JSON, CSV and EDI Transmission formats** 38 38 ... ... @@ -63,7 +63,8 @@ 63 63 64 64 == //2.1 Web Services API// == 65 65 66 -|**REST API**|((( 70 +(% style="width:948.039px" %) 71 +|**REST API**|(% style="width:818px" %)((( 67 67 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: 68 68 69 69 * Structure queries ... ... @@ -79,14 +79,13 @@ 79 79 80 80 Implementors are also recommended to version their API services providing users with an explicit choice of which version to use. 81 81 ))) 82 -|**SOAP API**|The SOAP API has been deprecated. 87 +|**SOAP API**|(% style="width:818px" %)The SOAP API has been deprecated. 83 83 84 84 == //2.2 Transmission Formats// == 85 85 86 -: 87 - 88 88 ((( 89 -|**SDMX-ML**|((( 92 +(% style="width:952.039px" %) 93 +|(% style="width:130px" %)**SDMX-ML**|(% style="width:820px" %)((( 90 90 The following legacy XML data messages have been deprecated: 91 91 92 92 SDMX-ML 1.0/2.0 Generic (time-series) data message ... ... @@ -102,34 +102,27 @@ 102 102 The SDMX-ML structure message is not backwardly compatible primarily due to: 103 103 104 104 * Changes to the information model 105 -* Changes to the way the structures are organised into 106 - 107 -‘collections’ within the message 108 - 109 +* Changes to the way the structures are organised into ‘collections’ within the message 109 109 * Deprecation of the Agency, ID, Version option for referencing of structures in messages 110 110 ))) 111 -|**SDMX-JSON**|((( 112 +|(% style="width:130px" %)**SDMX-JSON**|(% style="width:820px" %)((( 112 112 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. 113 113 114 114 The JSON structure message is not backwardly compatible primarily due to: 115 115 116 116 * Changes to the information model 117 -* Changes to the way the structures are organised into 118 - 119 -‘collections’ within the message 120 - 118 +* Changes to the way the structures are organised into ‘collections’ within the message 121 121 * Deprecation of the Agency, ID, Version option for referencing of structures in messages 122 122 ))) 123 -|**SDMX-EDI**|The EDI format for both structures and data has been deprecated. 124 -|**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. ** **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. 125 125 ))) 126 126 127 127 == //2.3 Information Model// == 128 128 129 -: 130 - 131 131 ((( 132 -|**Data Structure Definition**|((( 128 +(% style="width:955.039px" %) 129 +|(% style="width:132px" %)**Data Structure Definition**|(% style="width:819px" %)((( 133 133 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. 134 134 135 135 //Conversion guidance for implementors// ... ... @@ -138,7 +138,7 @@ 138 138 139 139 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. 140 140 ))) 141 -|**Structure mapping model**|((( 138 +|(% style="width:132px" %)**Structure mapping model**|(% style="width:819px" %)((( 142 142 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. 143 143 144 144 //Conversion guidance for implementors// ... ... @@ -147,7 +147,7 @@ 147 147 148 148 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. 149 149 ))) 150 -|**Reference metadata model**|((( 147 +|(% style="width:132px" %)**Reference metadata model**|(% style="width:819px" %)((( 151 151 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. 152 152 153 153 Version 2.1 reference metadata models are not valid in version 3.0. ... ... @@ -154,14 +154,11 @@ 154 154 155 155 //Conversion guidance for implementors// 156 156 157 -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 158 -))) 159 -| |((( 160 -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. 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. 161 161 162 162 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. 163 163 ))) 164 -|**Constraint model**|((( 158 +|(% style="width:132px" %)**Constraint model**|(% style="width:819px" %)((( 165 165 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. 166 166 167 167 //Conversion guidance for implementors// ... ... @@ -170,7 +170,7 @@ 170 170 171 171 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. 172 172 ))) 173 -|**Hierarchical codelist structures**|((( 167 +|(% style="width:132px" %)**Hierarchical codelist structures**|(% style="width:819px" %)((( 174 174 The version 2.1 Hierarchical Codelist artefact has been deprecated in version 3.0 and replaced by two new artefacts, Hierarchy and Hierarchy Association. 175 175 176 176 //Conversion guidance for implementors// ... ... @@ -504,7 +504,7 @@ 504 504 505 505 = 4 Versioning of Structural Metadata Artefacts = 506 506 507 -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.501 +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. 508 508 509 509 Semantic version numbers are three digits: 510 510 ... ... @@ -586,11 +586,12 @@ 586 586 587 587 /data/dataflow/ESTAT/ICP?c[REF_AREA]=DE&c[ICP_ITEM]=sw:01&c[TIME_PERIOD]=ge:2015 Operators include: 588 588 589 -|eq|Equals 590 -|ne|Not equal to 591 -|le|Less than 592 -|ge|Greater than or equal to 593 -|sw|Starts with 583 +(% style="width:531.039px" %) 584 +|(% style="width:151px" %)eq|(% style="width:378px" %)Equals 585 +|(% style="width:151px" %)ne|(% style="width:378px" %)Not equal to 586 +|(% style="width:151px" %)le|(% style="width:378px" %)Less than 587 +|(% style="width:151px" %)ge|(% style="width:378px" %)Greater than or equal to 588 +|(% style="width:151px" %)sw|(% style="width:378px" %)Starts with 594 594 595 595 === Support for multiple keys === 596 596 ... ... @@ -632,47 +632,49 @@ 632 632 633 633 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: 634 634 635 -|**Artefact type**|**Version 2.1 Collection**|**Version 3.0 Collection** 636 -|AgencyScheme|OrganisationSchemes|AgencySchemes 637 -|DataConsumerScheme|OrganisationSchemes|DataConsumerSchemes 638 -|DataProviderScheme|OrganisationSchemes|DataProviderSchemes 639 -|MetadataProviderScheme|OrganisationSchemes|MetadataProviderSchemes 640 -|OrganisationUnitScheme|OrganisationSchemes|OrganisationUnitSchemes 641 -|GeographicCodelist|Codelists|GeographicCodelists 642 -|GeoGridCodelist|Codelists|GeoGridCodelists 643 -|ConceptScheme|Concepts|ConceptSchemes 644 -|ValueList|Codelists|ValueLists 645 -|StructureMap|StructureMappings|StructureMaps 646 -|RepresentationMap|StructureMappings|RepresentationMaps 647 -|ConceptSchemeMap|StructureMappings|ConceptSchemeMaps 648 -|CategorySchemeMap|StructureMappings|CategorySchemeMaps 649 -|OrganisationSchemeMap|StructureMappings|OrganisationSchemeMaps 650 -|ReportingTaxonomyMap|StructureMappings|ReportingTaxonomyMaps 651 -|DataConstraint|Constraints|DataConstraints 652 -|MetadataConstraint|Constraints|MetadataConstraints 653 -|MetadataProvisionAgreement|ProvisionAgreement|MetadataProvisionAgreements 654 -|CustomTypeScheme|CustomTypes|CustomTypeSchemes 655 -|VtlMappingScheme|VtlMappings|VtlMappingSchemes 656 -|NamePersonalisationScheme|NamePersonalisations|NamePersonalisationSchemes 657 -|RulesetScheme|Rulesets|RulesetSchemes 658 -|TransformationScheme|Transformations|TransformationSchemes 659 -|UserDefinedOperatorScheme|UserDefinedOperators|UserDefinedOperatorSchemes 630 +(% style="width:1102.04px" %) 631 +|(% style="width:321px" %)**Artefact type**|(% style="width:351px" %)**Version 2.1 Collection**|(% style="width:426px" %)**Version 3.0 Collection** 632 +|(% style="width:321px" %)AgencyScheme|(% style="width:351px" %)OrganisationSchemes|(% style="width:426px" %)AgencySchemes 633 +|(% style="width:321px" %)DataConsumerScheme|(% style="width:351px" %)OrganisationSchemes|(% style="width:426px" %)DataConsumerSchemes 634 +|(% style="width:321px" %)DataProviderScheme|(% style="width:351px" %)OrganisationSchemes|(% style="width:426px" %)DataProviderSchemes 635 +|(% style="width:321px" %)MetadataProviderScheme|(% style="width:351px" %)OrganisationSchemes|(% style="width:426px" %)MetadataProviderSchemes 636 +|(% style="width:321px" %)OrganisationUnitScheme|(% style="width:351px" %)OrganisationSchemes|(% style="width:426px" %)OrganisationUnitSchemes 637 +|(% style="width:321px" %)GeographicCodelist|(% style="width:351px" %)Codelists|(% style="width:426px" %)GeographicCodelists 638 +|(% style="width:321px" %)GeoGridCodelist|(% style="width:351px" %)Codelists|(% style="width:426px" %)GeoGridCodelists 639 +|(% style="width:321px" %)ConceptScheme|(% style="width:351px" %)Concepts|(% style="width:426px" %)ConceptSchemes 640 +|(% style="width:321px" %)ValueList|(% style="width:351px" %)Codelists|(% style="width:426px" %)ValueLists 641 +|(% style="width:321px" %)StructureMap|(% style="width:351px" %)StructureMappings|(% style="width:426px" %)StructureMaps 642 +|(% style="width:321px" %)RepresentationMap|(% style="width:351px" %)StructureMappings|(% style="width:426px" %)RepresentationMaps 643 +|(% style="width:321px" %)ConceptSchemeMap|(% style="width:351px" %)StructureMappings|(% style="width:426px" %)ConceptSchemeMaps 644 +|(% style="width:321px" %)CategorySchemeMap|(% style="width:351px" %)StructureMappings|(% style="width:426px" %)CategorySchemeMaps 645 +|(% style="width:321px" %)OrganisationSchemeMap|(% style="width:351px" %)StructureMappings|(% style="width:426px" %)OrganisationSchemeMaps 646 +|(% style="width:321px" %)ReportingTaxonomyMap|(% style="width:351px" %)StructureMappings|(% style="width:426px" %)ReportingTaxonomyMaps 647 +|(% style="width:321px" %)DataConstraint|(% style="width:351px" %)Constraints|(% style="width:426px" %)DataConstraints 648 +|(% style="width:321px" %)MetadataConstraint|(% style="width:351px" %)Constraints|(% style="width:426px" %)MetadataConstraints 649 +|(% style="width:321px" %)MetadataProvisionAgreement|(% style="width:351px" %)ProvisionAgreement|(% style="width:426px" %)MetadataProvisionAgreements 650 +|(% style="width:321px" %)CustomTypeScheme|(% style="width:351px" %)CustomTypes|(% style="width:426px" %)CustomTypeSchemes 651 +|(% style="width:321px" %)VtlMappingScheme|(% style="width:351px" %)VtlMappings|(% style="width:426px" %)VtlMappingSchemes 652 +|(% style="width:321px" %)NamePersonalisationScheme|(% style="width:351px" %)NamePersonalisations|(% style="width:426px" %)NamePersonalisationSchemes 653 +|(% style="width:321px" %)RulesetScheme|(% style="width:351px" %)Rulesets|(% style="width:426px" %)RulesetSchemes 654 +|(% style="width:321px" %)TransformationScheme|(% style="width:351px" %)Transformations|(% style="width:426px" %)TransformationSchemes 655 +|(% style="width:321px" %)UserDefinedOperatorScheme|(% style="width:351px" %)UserDefinedOperators|(% style="width:426px" %)UserDefinedOperatorSchemes 660 660 661 661 No changes have been made to the way the following artefacts are organised in the structure message: 662 662 663 -|**Artefact type**|**Collection** 664 -|Dataflow|Dataflows 665 -|Metadataflow|Metadataflows 666 -|CategoryScheme|CategorySchemes 667 -|Categorisation|Categorisations 668 -|Codelist|Codelists 669 -|Hierarchy|Hierarchies 670 -|HierarchyAssociation|HierarchyAssociations 671 -|MetadataStructure|MetadataStructures 672 -|DataStructure|DataStructures 673 -|ReportingTaxonomy|ReportingTaxonomies 674 -|Process|Processes 675 -|ProvisionAgreement|ProvisionAgreements 659 +(% style="width:1106.04px" %) 660 +|(% style="width:326px" %)**Artefact type**|(% style="width:776px" %)**Collection** 661 +|(% style="width:326px" %)Dataflow|(% style="width:776px" %)Dataflows 662 +|(% style="width:326px" %)Metadataflow|(% style="width:776px" %)Metadataflows 663 +|(% style="width:326px" %)CategoryScheme|(% style="width:776px" %)CategorySchemes 664 +|(% style="width:326px" %)Categorisation|(% style="width:776px" %)Categorisations 665 +|(% style="width:326px" %)Codelist|(% style="width:776px" %)Codelists 666 +|(% style="width:326px" %)Hierarchy|(% style="width:776px" %)Hierarchies 667 +|(% style="width:326px" %)HierarchyAssociation|(% style="width:776px" %)HierarchyAssociations 668 +|(% style="width:326px" %)MetadataStructure|(% style="width:776px" %)MetadataStructures 669 +|(% style="width:326px" %)DataStructure|(% style="width:776px" %)DataStructures 670 +|(% style="width:326px" %)ReportingTaxonomy|(% style="width:776px" %)ReportingTaxonomies 671 +|(% style="width:326px" %)Process|(% style="width:776px" %)Processes 672 +|(% style="width:326px" %)ProvisionAgreement|(% style="width:776px" %)ProvisionAgreements 676 676 677 677 From version 3.0, collections can appear in any order within a structure message. 678 678