Skip to Content
Last modified by Helena on 2025/09/10 11:19
From version 7.2
edited by Helena
on 2025/05/14 13:28
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
... ... @@ -4,9 +4,10 @@
4 4  
5 5  **Revision History**
6 6  
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
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
10 10  
11 11  = 1 Overview =
12 12  
... ... @@ -24,7 +24,7 @@
24 24  
25 25  **Versioning of Structural Metadata Artefacts**
26 26  
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/]]
28 +* Adoption of the three-number semantic versioning standard for structural metadata artefacts ([[https:~~/~~/semver.org/>>https://semver.org/||rel="noopener noreferrer" target="_blank"]])
28 28  
29 29  **REST Web Services Application Programming Interface (API)**
30 30  
... ... @@ -35,7 +35,7 @@
35 35  
36 36  **SOAP Web Services API**
37 37  
38 -• 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**;**
39 39  
40 40  **XML, JSON, CSV and EDI Transmission formats**
41 41  
... ... @@ -66,7 +66,8 @@
66 66  
67 67  == //2.1 Web Services API// ==
68 68  
69 -|**REST API**|(((
70 +(% style="width:948.039px" %)
71 +|**REST API**|(% style="width:818px" %)(((
70 70  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:
71 71  
72 72  * Structure queries
... ... @@ -82,14 +82,13 @@
82 82  
83 83  Implementors are also recommended to version their API services providing users with an explicit choice of which version to use.
84 84  )))
85 -|**SOAP API**|The SOAP API has been deprecated.
87 +|**SOAP API**|(% style="width:818px" %)The SOAP API has been deprecated.
86 86  
87 87  == //2.2 Transmission Formats// ==
88 88  
89 -:
90 -
91 91  (((
92 -|**SDMX-ML**|(((
92 +(% style="width:952.039px" %)
93 +|(% style="width:130px" %)**SDMX-ML**|(% style="width:820px" %)(((
93 93  The following legacy XML data messages have been deprecated:
94 94  
95 95  SDMX-ML 1.0/2.0 Generic (time-series) data message
... ... @@ -105,34 +105,27 @@
105 105  The SDMX-ML structure message is not backwardly compatible primarily due to:
106 106  
107 107  * Changes to the information model
108 -* Changes to the way the structures are organised into
109 -
110 -‘collections’ within the message
111 -
109 +* Changes to the way the structures are organised into ‘collections’ within the message
112 112  * Deprecation of the Agency, ID, Version option for referencing of structures in messages
113 113  )))
114 -|**SDMX-JSON**|(((
112 +|(% style="width:130px" %)**SDMX-JSON**|(% style="width:820px" %)(((
115 115  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.
116 116  
117 117  The JSON structure message is not backwardly compatible primarily due to:
118 118  
119 119  * Changes to the information model
120 -* Changes to the way the structures are organised into
121 -
122 -‘collections’ within the message
123 -
118 +* Changes to the way the structures are organised into ‘collections’ within the message
124 124  * Deprecation of the Agency, ID, Version option for referencing of structures in messages
125 125  )))
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.**     **
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.
128 128  )))
129 129  
130 130  == //2.3 Information Model// ==
131 131  
132 -:
133 -
134 134  (((
135 -|**Data Structure Definition**|(((
128 +(% style="width:955.039px" %)
129 +|(% style="width:132px" %)**Data Structure Definition**|(% style="width:819px" %)(((
136 136  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.
137 137  
138 138  //Conversion guidance for implementors//
... ... @@ -141,7 +141,7 @@
141 141  
142 142  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.
143 143  )))
144 -|**Structure mapping model**|(((
138 +|(% style="width:132px" %)**Structure mapping model**|(% style="width:819px" %)(((
145 145  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.
146 146  
147 147  //Conversion guidance for implementors//
... ... @@ -150,7 +150,7 @@
150 150  
151 151  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.
152 152  )))
153 -|**Reference metadata model**|(((
147 +|(% style="width:132px" %)**Reference metadata model**|(% style="width:819px" %)(((
154 154  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.
155 155  
156 156  Version 2.1 reference metadata models are not valid in version 3.0.
... ... @@ -157,14 +157,11 @@
157 157  
158 158  //Conversion guidance for implementors//
159 159  
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.
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.
164 164  
165 165  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.
166 166  )))
167 -|**Constraint model**|(((
158 +|(% style="width:132px" %)**Constraint model**|(% style="width:819px" %)(((
168 168  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.
169 169  
170 170  //Conversion guidance for implementors//
... ... @@ -173,7 +173,7 @@
173 173  
174 174  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.
175 175  )))
176 -|**Hierarchical codelist structures**|(((
167 +|(% style="width:132px" %)**Hierarchical codelist structures**|(% style="width:819px" %)(((
177 177  The version 2.1 Hierarchical Codelist artefact has been deprecated in version 3.0 and replaced by two new artefacts, Hierarchy and Hierarchy Association.
178 178  
179 179  //Conversion guidance for implementors//
... ... @@ -224,7 +224,8 @@
224 224  Removed Maintainable Artefacts
225 225  
226 226  * Structure Set – replaced by Structure Map and the four item scheme maps
227 -* 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
228 228  
229 229  Changed Maintainable Artefacts
230 230  
... ... @@ -238,7 +238,7 @@
238 238  
239 239  * GeospatialInformation – a string type where the value is an expression defining a set of geographical features using a purpose-designed syntax
240 240  
241 -== //3.3 Areas Unchanged from Version 2.1// ==
233 +== 3.3 Areas Unchanged from Version 2.1 ==
242 242  
243 243  The following areas of the information model are unchanged from version 2.1:
244 244  
... ... @@ -251,7 +251,7 @@
251 251  * Reporting taxonomy
252 252  * Process
253 253  
254 -== //3.4 Reference Metadata// ==
246 +== 3.4 Reference Metadata ==
255 255  
256 256  Reference metadata has been substantially re-designed for version 3.0 to simplify the model and better support practical use cases.
257 257  
... ... @@ -280,83 +280,45 @@
280 280  * SOURCE_AGENCY – a multi-value data attribute
281 281  
282 282  <Obs xsi:type="dsd:ObsType" OBS_VALUE="112" OBS_STAUS=”A” TIME_PERIOD="2010-09">
283 -
284 284  <!—- complex multi-value and multi-lingual data attributes ~-~->
285 -
286 286  <Comp id="TITLE" xsi:type="ns1:TITLE_ATTRIBUTE">
287 -
288 288  <Value>
289 -
290 290  <common:Text xml:lang="en">Some English Text</common:Text>
291 -
292 292  <common:Text xml:lang="fr">Quelques textes en anglais</common:Text>
293 -
294 294  </Value>
295 -
296 296  </Comp>
297 297  
298 298  <Comp id="SOURCE_AGENCY" xsi:type="ns1:SOURCE_AGENCY_ATTRIBUTE">
299 -
300 300  <Value>4F0</Value>
301 -
302 302  <Value>4D0</Value>
303 -
304 304  <Value>CZ2</Value>
305 -
306 306  </Comp>
307 -
308 308  <!—- metadata attributes are reported like in metadata messages ~-~->
309 -
310 310  <Metadata>
311 -
312 312  <Attribute id="COLLECTION">
313 -
314 314  <Attribute id="METHOD">
315 -
316 316  <Text lang="en">AAA</Text>
317 -
318 318  </Attribute>
319 -
320 320  </Attribute>
321 -
322 322  <Attribute id="CONTACT">
323 -
324 324  <Value>CONTACT 1</Value>
325 -
326 326  <Attribute id="NAME">
327 -
328 328  <Value>Contact 1 Name 1</Value>
329 -
330 330  </Attribute>
331 -
332 332  <Attribute id="NAME">
333 -
334 334  <Value>Contact 1 Name 2</Value>
335 -
336 336  </Attribute>
337 -
338 338  </Attribute>
339 -
340 340  <Attribute id="CONTACT">
341 -
342 342  <Value>CONTACT 2</Value>
343 -
344 344  <Attribute id="NAME">
345 -
346 346  <Value>Contact 2 Name 1</Value>
347 -
348 348  </Attribute>
349 -
350 350  <Attribute id="NAME">
351 -
352 352  <Value>Contact 2 Name 2</Value>
353 -
354 354  </Attribute>
355 -
356 356  </Attribute>
357 -
358 358  </Metadata>
359 -
360 360  </Obs>
361 361  
362 362  === New - Metadata Provision Agreement ===
... ... @@ -371,7 +371,7 @@
371 371  
372 372  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.
373 373  
374 -== //3.5 Microdata Exchange// ==
328 +== 3.5 Microdata Exchange ==
375 375  
376 376  Several changes have been made the Data Structure Definition to support microdata use cases in addition to aggregated time series.
377 377  
... ... @@ -429,7 +429,7 @@
429 429  
430 430  That allows ValueItems (the equivalent to Code) to contain symbols like ‘¥’ and ‘€’, but 208 also means they are not identifiable.
431 431  
432 -== //3.6 Geospatial Data Exchange// ==
386 +== 3.6 Geospatial Data Exchange ==
433 433  
434 434  The version 3.0 model has been extended to provide explicit support for geospatial data.
435 435  
... ... @@ -444,7 +444,7 @@
444 444  * 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.
445 445  * 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.
446 446  
447 -=== //3.7 Structure Mapping// ===
401 +=== 3.7 Structure Mapping ===
448 448  
449 449  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.
450 450  
... ... @@ -476,7 +476,7 @@
476 476  
477 477  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.
478 478  
479 -=== //3.8 Constraints// ===
433 +=== 3.8 Constraints ===
480 480  
481 481  Constraints in version 3.0 are modelled using two separate artefacts which replace the version 2.1 content constraint:
482 482  
... ... @@ -491,23 +491,23 @@
491 491  
492 492  Attachment constraints have been deprecated due to a lack of use cases.
493 493  
494 -=== //3.9 Code List Extension// ===
448 +=== 3.9 Code List Extension ===
495 495  
496 496  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.
497 497  
498 498  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.
499 499  
500 -=== //3.10 Discriminated Union of Code Lists// ===
454 +=== 3.10 Discriminated Union of Code Lists ===
501 501  
502 502  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.
503 503  
504 -=== //3.11 Code Hierarchies// ===
458 +=== 3.11 Code Hierarchies ===
505 505  
506 506  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).
507 507  
508 508  = 4 Versioning of Structural Metadata Artefacts =
509 509  
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.
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.
511 511  
512 512  Semantic version numbers are three digits:
513 513  
... ... @@ -589,11 +589,12 @@
589 589  
590 590  /data/dataflow/ESTAT/ICP?c[REF_AREA]=DE&c[ICP_ITEM]=sw:01&c[TIME_PERIOD]=ge:2015 Operators include:
591 591  
592 -|eq|Equals
593 -|ne|Not equal to
594 -|le|Less than
595 -|ge|Greater than or equal to
596 -|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
597 597  
598 598  === Support for multiple keys ===
599 599  
... ... @@ -635,47 +635,49 @@
635 635  
636 636  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:
637 637  
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
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
663 663  
664 664  No changes have been made to the way the following artefacts are organised in the structure message:
665 665  
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
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
679 679  
680 680  From version 3.0, collections can appear in any order within a structure message.
681 681  
SUZ.Methodology.Code.MethodologyClass[0]