Skip to Content
Last modified by Helena on 2025/09/10 11:19
From version 10.2
edited by Helena
on 2025/05/14 14:41
Change comment: There is no comment for this version
To version 8.2
edited by Helena
on 2025/05/14 13:39
Change comment: Update document after refactoring.

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -SDMX STANDARDS
1 +SDMX STANDARDS1
Content
... ... @@ -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  
... ... @@ -383,7 +383,7 @@
383 383  
384 384  That allows ValueItems (the equivalent to Code) to contain symbols like ‘¥’ and ‘€’, but 208 also means they are not identifiable.
385 385  
386 -== 3.6 Geospatial Data Exchange ==
424 +== //3.6 Geospatial Data Exchange// ==
387 387  
388 388  The version 3.0 model has been extended to provide explicit support for geospatial data.
389 389  
... ... @@ -398,7 +398,7 @@
398 398  * 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.
399 399  * 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.
400 400  
401 -=== 3.7 Structure Mapping ===
439 +=== //3.7 Structure Mapping// ===
402 402  
403 403  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.
404 404  
... ... @@ -430,7 +430,7 @@
430 430  
431 431  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.
432 432  
433 -=== 3.8 Constraints ===
471 +=== //3.8 Constraints// ===
434 434  
435 435  Constraints in version 3.0 are modelled using two separate artefacts which replace the version 2.1 content constraint:
436 436  
... ... @@ -445,17 +445,17 @@
445 445  
446 446  Attachment constraints have been deprecated due to a lack of use cases.
447 447  
448 -=== 3.9 Code List Extension ===
486 +=== //3.9 Code List Extension// ===
449 449  
450 450  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.
451 451  
452 452  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.
453 453  
454 -=== 3.10 Discriminated Union of Code Lists ===
492 +=== //3.10 Discriminated Union of Code Lists// ===
455 455  
456 456  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.
457 457  
458 -=== 3.11 Code Hierarchies ===
496 +=== //3.11 Code Hierarchies// ===
459 459  
460 460  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).
461 461  
SUZ.Methodology.Code.MethodologyClass[0]