Skip to Content
Last modified by Helena on 2025/09/10 11:19
From version 7.1
edited by Helena
on 2025/05/14 13:27
Change comment: There is no comment for this version
To version 10.2
edited by Helena
on 2025/05/14 14:41
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -1 Overview
1 +SDMX STANDARDS
Parent
... ... @@ -1,0 +1,1 @@
1 +Methodology.WebHome
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//
... ... @@ -221,7 +221,8 @@
221 221  Removed Maintainable Artefacts
222 222  
223 223  * Structure Set – replaced by Structure Map and the four item scheme maps
224 -* Hierarchical Codelist – replaced by Hierarchy and Hierarchy Association • Constraint – replaced by Data Constraint and Metadata Constraint
218 +* Hierarchical Codelist – replaced by Hierarchy and Hierarchy Association
219 +* Constraint – replaced by Data Constraint and Metadata Constraint
225 225  
226 226  Changed Maintainable Artefacts
227 227  
... ... @@ -235,7 +235,7 @@
235 235  
236 236  * GeospatialInformation – a string type where the value is an expression defining a set of geographical features using a purpose-designed syntax
237 237  
238 -== //3.3 Areas Unchanged from Version 2.1// ==
233 +== 3.3 Areas Unchanged from Version 2.1 ==
239 239  
240 240  The following areas of the information model are unchanged from version 2.1:
241 241  
... ... @@ -248,7 +248,7 @@
248 248  * Reporting taxonomy
249 249  * Process
250 250  
251 -== //3.4 Reference Metadata// ==
246 +== 3.4 Reference Metadata ==
252 252  
253 253  Reference metadata has been substantially re-designed for version 3.0 to simplify the model and better support practical use cases.
254 254  
... ... @@ -277,83 +277,45 @@
277 277  * SOURCE_AGENCY – a multi-value data attribute
278 278  
279 279  <Obs xsi:type="dsd:ObsType" OBS_VALUE="112" OBS_STAUS=”A” TIME_PERIOD="2010-09">
280 -
281 281  <!—- complex multi-value and multi-lingual data attributes ~-~->
282 -
283 283  <Comp id="TITLE" xsi:type="ns1:TITLE_ATTRIBUTE">
284 -
285 285  <Value>
286 -
287 287  <common:Text xml:lang="en">Some English Text</common:Text>
288 -
289 289  <common:Text xml:lang="fr">Quelques textes en anglais</common:Text>
290 -
291 291  </Value>
292 -
293 293  </Comp>
294 294  
295 295  <Comp id="SOURCE_AGENCY" xsi:type="ns1:SOURCE_AGENCY_ATTRIBUTE">
296 -
297 297  <Value>4F0</Value>
298 -
299 299  <Value>4D0</Value>
300 -
301 301  <Value>CZ2</Value>
302 -
303 303  </Comp>
304 -
305 305  <!—- metadata attributes are reported like in metadata messages ~-~->
306 -
307 307  <Metadata>
308 -
309 309  <Attribute id="COLLECTION">
310 -
311 311  <Attribute id="METHOD">
312 -
313 313  <Text lang="en">AAA</Text>
314 -
315 315  </Attribute>
316 -
317 317  </Attribute>
318 -
319 319  <Attribute id="CONTACT">
320 -
321 321  <Value>CONTACT 1</Value>
322 -
323 323  <Attribute id="NAME">
324 -
325 325  <Value>Contact 1 Name 1</Value>
326 -
327 327  </Attribute>
328 -
329 329  <Attribute id="NAME">
330 -
331 331  <Value>Contact 1 Name 2</Value>
332 -
333 333  </Attribute>
334 -
335 335  </Attribute>
336 -
337 337  <Attribute id="CONTACT">
338 -
339 339  <Value>CONTACT 2</Value>
340 -
341 341  <Attribute id="NAME">
342 -
343 343  <Value>Contact 2 Name 1</Value>
344 -
345 345  </Attribute>
346 -
347 347  <Attribute id="NAME">
348 -
349 349  <Value>Contact 2 Name 2</Value>
350 -
351 351  </Attribute>
352 -
353 353  </Attribute>
354 -
355 355  </Metadata>
356 -
357 357  </Obs>
358 358  
359 359  === New - Metadata Provision Agreement ===
... ... @@ -368,7 +368,7 @@
368 368  
369 369  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.
370 370  
371 -== //3.5 Microdata Exchange// ==
328 +== 3.5 Microdata Exchange ==
372 372  
373 373  Several changes have been made the Data Structure Definition to support microdata use cases in addition to aggregated time series.
374 374  
... ... @@ -426,7 +426,7 @@
426 426  
427 427  That allows ValueItems (the equivalent to Code) to contain symbols like ‘¥’ and ‘€’, but 208 also means they are not identifiable.
428 428  
429 -== //3.6 Geospatial Data Exchange// ==
386 +== 3.6 Geospatial Data Exchange ==
430 430  
431 431  The version 3.0 model has been extended to provide explicit support for geospatial data.
432 432  
... ... @@ -441,7 +441,7 @@
441 441  * 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.
442 442  * 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.
443 443  
444 -=== //3.7 Structure Mapping// ===
401 +=== 3.7 Structure Mapping ===
445 445  
446 446  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.
447 447  
... ... @@ -473,7 +473,7 @@
473 473  
474 474  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.
475 475  
476 -=== //3.8 Constraints// ===
433 +=== 3.8 Constraints ===
477 477  
478 478  Constraints in version 3.0 are modelled using two separate artefacts which replace the version 2.1 content constraint:
479 479  
... ... @@ -488,23 +488,23 @@
488 488  
489 489  Attachment constraints have been deprecated due to a lack of use cases.
490 490  
491 -=== //3.9 Code List Extension// ===
448 +=== 3.9 Code List Extension ===
492 492  
493 493  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.
494 494  
495 495  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.
496 496  
497 -=== //3.10 Discriminated Union of Code Lists// ===
454 +=== 3.10 Discriminated Union of Code Lists ===
498 498  
499 499  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.
500 500  
501 -=== //3.11 Code Hierarchies// ===
458 +=== 3.11 Code Hierarchies ===
502 502  
503 503  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).
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.
464 +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
546 +(% style="width:531.039px" %)
547 +|(% style="width:151px" %)eq|(% style="width:378px" %)Equals
548 +|(% style="width:151px" %)ne|(% style="width:378px" %)Not equal to
549 +|(% style="width:151px" %)le|(% style="width:378px" %)Less than
550 +|(% style="width:151px" %)ge|(% style="width:378px" %)Greater than or equal to
551 +|(% 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
593 +(% style="width:1102.04px" %)
594 +|(% style="width:321px" %)**Artefact type**|(% style="width:351px" %)**Version 2.1 Collection**|(% style="width:426px" %)**Version 3.0 Collection**
595 +|(% style="width:321px" %)AgencyScheme|(% style="width:351px" %)OrganisationSchemes|(% style="width:426px" %)AgencySchemes
596 +|(% style="width:321px" %)DataConsumerScheme|(% style="width:351px" %)OrganisationSchemes|(% style="width:426px" %)DataConsumerSchemes
597 +|(% style="width:321px" %)DataProviderScheme|(% style="width:351px" %)OrganisationSchemes|(% style="width:426px" %)DataProviderSchemes
598 +|(% style="width:321px" %)MetadataProviderScheme|(% style="width:351px" %)OrganisationSchemes|(% style="width:426px" %)MetadataProviderSchemes
599 +|(% style="width:321px" %)OrganisationUnitScheme|(% style="width:351px" %)OrganisationSchemes|(% style="width:426px" %)OrganisationUnitSchemes
600 +|(% style="width:321px" %)GeographicCodelist|(% style="width:351px" %)Codelists|(% style="width:426px" %)GeographicCodelists
601 +|(% style="width:321px" %)GeoGridCodelist|(% style="width:351px" %)Codelists|(% style="width:426px" %)GeoGridCodelists
602 +|(% style="width:321px" %)ConceptScheme|(% style="width:351px" %)Concepts|(% style="width:426px" %)ConceptSchemes
603 +|(% style="width:321px" %)ValueList|(% style="width:351px" %)Codelists|(% style="width:426px" %)ValueLists
604 +|(% style="width:321px" %)StructureMap|(% style="width:351px" %)StructureMappings|(% style="width:426px" %)StructureMaps
605 +|(% style="width:321px" %)RepresentationMap|(% style="width:351px" %)StructureMappings|(% style="width:426px" %)RepresentationMaps
606 +|(% style="width:321px" %)ConceptSchemeMap|(% style="width:351px" %)StructureMappings|(% style="width:426px" %)ConceptSchemeMaps
607 +|(% style="width:321px" %)CategorySchemeMap|(% style="width:351px" %)StructureMappings|(% style="width:426px" %)CategorySchemeMaps
608 +|(% style="width:321px" %)OrganisationSchemeMap|(% style="width:351px" %)StructureMappings|(% style="width:426px" %)OrganisationSchemeMaps
609 +|(% style="width:321px" %)ReportingTaxonomyMap|(% style="width:351px" %)StructureMappings|(% style="width:426px" %)ReportingTaxonomyMaps
610 +|(% style="width:321px" %)DataConstraint|(% style="width:351px" %)Constraints|(% style="width:426px" %)DataConstraints
611 +|(% style="width:321px" %)MetadataConstraint|(% style="width:351px" %)Constraints|(% style="width:426px" %)MetadataConstraints
612 +|(% style="width:321px" %)MetadataProvisionAgreement|(% style="width:351px" %)ProvisionAgreement|(% style="width:426px" %)MetadataProvisionAgreements
613 +|(% style="width:321px" %)CustomTypeScheme|(% style="width:351px" %)CustomTypes|(% style="width:426px" %)CustomTypeSchemes
614 +|(% style="width:321px" %)VtlMappingScheme|(% style="width:351px" %)VtlMappings|(% style="width:426px" %)VtlMappingSchemes
615 +|(% style="width:321px" %)NamePersonalisationScheme|(% style="width:351px" %)NamePersonalisations|(% style="width:426px" %)NamePersonalisationSchemes
616 +|(% style="width:321px" %)RulesetScheme|(% style="width:351px" %)Rulesets|(% style="width:426px" %)RulesetSchemes
617 +|(% style="width:321px" %)TransformationScheme|(% style="width:351px" %)Transformations|(% style="width:426px" %)TransformationSchemes
618 +|(% 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
622 +(% style="width:1106.04px" %)
623 +|(% style="width:326px" %)**Artefact type**|(% style="width:776px" %)**Collection**
624 +|(% style="width:326px" %)Dataflow|(% style="width:776px" %)Dataflows
625 +|(% style="width:326px" %)Metadataflow|(% style="width:776px" %)Metadataflows
626 +|(% style="width:326px" %)CategoryScheme|(% style="width:776px" %)CategorySchemes
627 +|(% style="width:326px" %)Categorisation|(% style="width:776px" %)Categorisations
628 +|(% style="width:326px" %)Codelist|(% style="width:776px" %)Codelists
629 +|(% style="width:326px" %)Hierarchy|(% style="width:776px" %)Hierarchies
630 +|(% style="width:326px" %)HierarchyAssociation|(% style="width:776px" %)HierarchyAssociations
631 +|(% style="width:326px" %)MetadataStructure|(% style="width:776px" %)MetadataStructures
632 +|(% style="width:326px" %)DataStructure|(% style="width:776px" %)DataStructures
633 +|(% style="width:326px" %)ReportingTaxonomy|(% style="width:776px" %)ReportingTaxonomies
634 +|(% style="width:326px" %)Process|(% style="width:776px" %)Processes
635 +|(% 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  
SUZ.Methodology.Code.MethodologyClass[0]