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

From version 13.1
edited by Helena
on 2025/05/14 14:53
Change comment: There is no comment for this version
To version 8.1
edited by Helena
on 2025/05/14 13:39
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -SDMX STANDARDS
1 +1 Overview
Parent
... ... @@ -1,1 +1,0 @@
1 -Methodology.WebHome
Content
... ... @@ -65,7 +65,7 @@
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 ==
68 +== //2.1 Web Services API// ==
69 69  
70 70  (% style="width:948.039px" %)
71 71  |**REST API**|(% style="width:818px" %)(((
... ... @@ -86,7 +86,7 @@
86 86  )))
87 87  |**SOAP API**|(% style="width:818px" %)The SOAP API has been deprecated.
88 88  
89 -== 2.2 Transmission Formats ==
89 +== //2.2 Transmission Formats// ==
90 90  
91 91  (((
92 92  (% style="width:952.039px" %)
... ... @@ -122,7 +122,7 @@
122 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.
123 123  )))
124 124  
125 -== 2.3 Information Model ==
125 +== //2.3 Information Model// ==
126 126  
127 127  (((
128 128  (% style="width:955.039px" %)
... ... @@ -177,7 +177,7 @@
177 177  
178 178  = 3 Information Model =
179 179  
180 -== 3.1 Version 3.0 Information Model ==
180 +== //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 ==
190 +== //3.2 Key Changes from Version 2.1// ==
191 191  
192 192  New Maintainable Artefacts
193 193  
... ... @@ -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 ==
233 +== //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 ==
246 +== //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  
... ... @@ -272,45 +272,83 @@
272 272  * SOURCE_AGENCY – a multi-value data attribute
273 273  
274 274  <Obs xsi:type="dsd:ObsType" OBS_VALUE="112" OBS_STAUS=”A” TIME_PERIOD="2010-09">
275 +
275 275  <!—- complex multi-value and multi-lingual data attributes ~-~->
277 +
276 276  <Comp id="TITLE" xsi:type="ns1:TITLE_ATTRIBUTE">
279 +
277 277  <Value>
281 +
278 278  <common:Text xml:lang="en">Some English Text</common:Text>
283 +
279 279  <common:Text xml:lang="fr">Quelques textes en anglais</common:Text>
285 +
280 280  </Value>
287 +
281 281  </Comp>
282 282  
283 283  <Comp id="SOURCE_AGENCY" xsi:type="ns1:SOURCE_AGENCY_ATTRIBUTE">
291 +
284 284  <Value>4F0</Value>
293 +
285 285  <Value>4D0</Value>
295 +
286 286  <Value>CZ2</Value>
297 +
287 287  </Comp>
299 +
288 288  <!—- metadata attributes are reported like in metadata messages ~-~->
301 +
289 289  <Metadata>
303 +
290 290  <Attribute id="COLLECTION">
305 +
291 291  <Attribute id="METHOD">
307 +
292 292  <Text lang="en">AAA</Text>
309 +
293 293  </Attribute>
311 +
294 294  </Attribute>
313 +
295 295  <Attribute id="CONTACT">
315 +
296 296  <Value>CONTACT 1</Value>
317 +
297 297  <Attribute id="NAME">
319 +
298 298  <Value>Contact 1 Name 1</Value>
321 +
299 299  </Attribute>
323 +
300 300  <Attribute id="NAME">
325 +
301 301  <Value>Contact 1 Name 2</Value>
327 +
302 302  </Attribute>
329 +
303 303  </Attribute>
331 +
304 304  <Attribute id="CONTACT">
333 +
305 305  <Value>CONTACT 2</Value>
335 +
306 306  <Attribute id="NAME">
337 +
307 307  <Value>Contact 2 Name 1</Value>
339 +
308 308  </Attribute>
341 +
309 309  <Attribute id="NAME">
343 +
310 310  <Value>Contact 2 Name 2</Value>
345 +
311 311  </Attribute>
347 +
312 312  </Attribute>
349 +
313 313  </Metadata>
351 +
314 314  </Obs>
315 315  
316 316  === New - Metadata Provision Agreement ===
... ... @@ -325,7 +325,7 @@
325 325  
326 326  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.
327 327  
328 -== 3.5 Microdata Exchange ==
366 +== //3.5 Microdata Exchange// ==
329 329  
330 330  Several changes have been made the Data Structure Definition to support microdata use cases in addition to aggregated time series.
331 331  
... ... @@ -338,18 +338,31 @@
338 338  MeasureDimension behaviour as illustrated in the SDMX-ML example below:
339 339  
340 340  <str:MeasureList id=”MeasureDescriptor”>
379 +
341 341  <str:Measure id=”OBS_VALUE” minOccurs=”1” maxOccurs=”1” usage=”mandatory” > <str:ConceptIdentity>
381 +
342 342  <Ref id=”OBS_VALUE” maintainableParentID=”CONCEPTS” agencyID=”SDMX” maintainableParentVersion=”1.0.0” />
383 +
343 343  </str:ConceptIdentity>
385 +
344 344  <str:LocalRepresentation>
387 +
345 345  <str:TextFormat textType=”String” isMultiLingual=”true” />
389 +
346 346  </str:LocalRepresentation>
391 +
347 347  <str:ConceptRole>
393 +
348 348  <Ref id=”MEASURE” maintainableParentID=”SDMX_CONCEPT_ROLES” agencyID=”SDMX” maintainableParentVersion=”1.0.0” />
395 +
349 349  </str:ConceptRole>
397 +
350 350  </str:Measure>
399 +
351 351  ...
401 +
352 352  <str:Measure>
403 +
353 353  </str:MeasureList>
354 354  
355 355  === Multi-value measures and attributes ===
... ... @@ -370,7 +370,7 @@
370 370  
371 371  That allows ValueItems (the equivalent to Code) to contain symbols like ‘¥’ and ‘€’, but 208 also means they are not identifiable.
372 372  
373 -== 3.6 Geospatial Data Exchange ==
424 +== //3.6 Geospatial Data Exchange// ==
374 374  
375 375  The version 3.0 model has been extended to provide explicit support for geospatial data.
376 376  
... ... @@ -385,13 +385,13 @@
385 385  * 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.
386 386  * 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.
387 387  
388 -== 3.7 Structure Mapping ==
439 +=== //3.7 Structure Mapping// ===
389 389  
390 390  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.
391 391  
392 392  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.
393 393  
394 -=== Many-to-many source and target components ===
445 +==== Many-to-many source and target components ====
395 395  
396 396  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:
397 397  
... ... @@ -405,19 +405,19 @@
405 405  
406 406  The Structure Map may now define input or output components which have a fixed value.
407 407  
408 -=== Time representations mapping ===
459 +==== Time representations mapping ====
409 409  
410 410  Non SDMX time representations may now be described in a Structure Map, allowing them to be mapped into SDMX time formats.
411 411  
412 -=== Regular expression and substring mappings ===
463 +==== Regular expression and substring mappings ====
413 413  
414 414  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.
415 415  
416 -=== Item maps validity period ===
467 +==== Item maps validity period ====
417 417  
418 418  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.
419 419  
420 -== 3.8 Constraints ==
471 +=== //3.8 Constraints// ===
421 421  
422 422  Constraints in version 3.0 are modelled using two separate artefacts which replace the version 2.1 content constraint:
423 423  
... ... @@ -432,17 +432,17 @@
432 432  
433 433  Attachment constraints have been deprecated due to a lack of use cases.
434 434  
435 -== 3.9 Code List Extension ==
486 +=== //3.9 Code List Extension// ===
436 436  
437 437  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.
438 438  
439 439  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.
440 440  
441 -== 3.10 Discriminated Union of Code Lists ==
492 +=== //3.10 Discriminated Union of Code Lists// ===
442 442  
443 443  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.
444 444  
445 -== 3.11 Code Hierarchies ==
496 +=== //3.11 Code Hierarchies// ===
446 446  
447 447  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).
448 448  
... ... @@ -490,7 +490,7 @@
490 490  
491 491  = 5 REST Web Services API =
492 492  
493 -== 5.1 Simplified list of resources ==
544 +== //5.1 Simplified list of resources// ==
494 494  
495 495  The version 3.0 REST API has just five main resources:
496 496  
... ... @@ -504,7 +504,7 @@
504 504  
505 505  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.
506 506  
507 -== 5.2 Improved data queries ==
558 +== //5.2 Improved data queries// ==
508 508  
509 509  Data queries have been changed to provide more granular selections from contexts wider than just a Dataflow.
510 510  
... ... @@ -543,7 +543,7 @@
543 543  
544 544  /data/dataflow/ESTAT/ICP/1.0.0/M…A.ANR,M…A.INX,M…B.CTG
545 545  
546 -== 5.3 Improved reference metadata queries ==
597 +== //5.3 Improved reference metadata queries// ==
547 547  
548 548  Reference metadata queries have been improved with a number of new options to retrieve metadata reports.
549 549  
... ... @@ -559,7 +559,7 @@
559 559  
560 560  /metadata/structure/datastructure/BIS/BIS_CBS/1.0
561 561  
562 -== 5.4 Structural metadata maintenance ==
613 +== //5.4 Structural metadata maintenance// ==
563 563  
564 564  Support has been added for maintenance of structural metadata.
565 565  
... ... @@ -567,7 +567,7 @@
567 567  
568 568  = 6 XML, JSON, CSV and EDI Transmission formats =
569 569  
570 -== 6.1 SDMX-ML ==
621 +== //6.1 SDMX-ML// ==
571 571  
572 572  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.
573 573  
... ... @@ -653,7 +653,7 @@
653 653  
654 654  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.
655 655  
656 -== 6.2 SDMX-JSON ==
707 +== //6.2 SDMX-JSON// ==
657 657  
658 658  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.
659 659  
... ... @@ -673,7 +673,7 @@
673 673  
674 674  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.
675 675  
676 -== 6.3 SDMX-CSV ==
727 +== //6.3 SDMX-CSV// ==
677 677  
678 678  CSV in SDMX is used transmission of data and reference metadata only.
679 679  
... ... @@ -691,7 +691,7 @@
691 691  
692 692  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.
693 693  
694 -=== 6.4 EDI deprecation ===
745 +=== //6.4 EDI deprecation// ===
695 695  
696 696  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.
697 697  
SUZ.Methodology.Code.MethodologyClass[0]