Skip to Content
Last modified by Artur K. on 2026/05/29 14:28
From version 1.19
edited by Helena K.
on 2026/01/15 12:54
Change comment: There is no comment for this version
To version 5.1
edited by Artur K.
on 2026/05/29 14:28
Change comment: Copied from sdmxsrlocalization:Methodology.Guidelines for SDMX Data Structure Definitions.WebHome

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -xwiki:XWiki.helena
1 +xwiki:XWiki.arturkryazhev
Content
... ... @@ -14,17 +14,17 @@
14 14  
15 15  Target audiences for these guidelines include domain experts and official statisticians involved in DSD development. Thus focusing on the business/content side of DSD development, the document tries to avoid technical jargon when explaining underlying concepts and ideas, but tries to still be useful for IT experts supporting SDMX implementations. Ideally, the document can bridge the gap between IT and statistical experts. The scope of the guidelines is restricted to conceptual aspects. Organizational and technical aspects are treated in separate documents.
16 16  
17 -* Code lists are the crucial building blocks of data structure definitions. Especially in the case of SDMX recommended code lists (particularly for cross-domain concepts; see SDMX Content Oriented Guidelines under “Guidelines” at http:~/~/sdmx.org/), list development and maintenance as well as DSD development and maintenance are carried out by different organizations at different points in time. For example SDMX recommended code lists for frequency and observation status already exist and should be used by reference in DSDs. While “SDMX” is responsible for the maintenance of these code lists, the DSD developing organization will be responsible for the maintenance of the DSD, that is, for the structure at a higher level. (Of course, a global DSD may also have “SDMX” as maintenance agency.) In any case, there is a strong interrelationship between DSD and code list development and maintenance (see SDMX Guidelines for the creation and maintenance of code lists under “Guidelines” at http:~/~/sdmx.org/).
18 -* Maintenance and governance rules for DSDs including issues of updating, versioning, retiring as well as questions of responsibilities, especially relevant in the context of global DSDs jointly developed by multiple organizations and maintained by “SDMX” (or multiple organizations), will be covered by separate guidelines (see “Guidelines” at http:~/~/sdmx.org/).
19 -* Issues related to SDMX registries (in general, and the global SDMX registry in particular) such as storage, federation, and registration of, as well as search for, retrieval and download of, code lists and DSDs are not in the scope of this document. For more information on the registry see the “Standards” page at http:~/~/sdmx.org/.
20 -* Guidelines for the development, maintenance, and governance of metadata structure definitions (MSDs) will be made available separately under “Guidelines” at http:~/~/sdmx.org/.
21 -* Documentation on more IT-related issues is available at the SDMX IT tools and SDMX tutorials site at http:~/~/sdmx.org/?page_id=13. The SDMX Tools Repository can be accessed at http:~/~/www.sdmxtools.org/. Many of the SDMX tools listed and described there are available free of charge.
17 +* Code lists are the crucial building blocks of data structure definitions. Especially in the case of SDMX recommended code lists (particularly for cross-domain concepts; see SDMX Content Oriented Guidelines under “Guidelines” at [[http:~~/~~/sdmx.org/>>https://http:sdmx.org]]), list development and maintenance as well as DSD development and maintenance are carried out by different organizations at different points in time. For example SDMX recommended code lists for frequency and observation status already exist and should be used by reference in DSDs. While “SDMX” is responsible for the maintenance of these code lists, the DSD developing organization will be responsible for the maintenance of the DSD, that is, for the structure at a higher level. (Of course, a global DSD may also have “SDMX” as maintenance agency.) In any case, there is a strong interrelationship between DSD and code list development and maintenance (see SDMX Guidelines for the creation and maintenance of code lists under “Guidelines” at [[http:~~/~~/sdmx.org/>>https://http:sdmx.org?page_id=13]]).
18 +* Maintenance and governance rules for DSDs including issues of updating, versioning, retiring as well as questions of responsibilities, especially relevant in the context of global DSDs jointly developed by multiple organizations and maintained by “SDMX” (or multiple organizations), will be covered by separate guidelines (see “Guidelines” at [[http:~~/~~/sdmx.org/>>https://http:sdmx.org]]).
19 +* Issues related to SDMX registries (in general, and the global SDMX registry in particular) such as storage, federation, and registration of, as well as search for, retrieval and download of, code lists and DSDs are not in the scope of this document. For more information on the registry see the “Standards” page at [[http:~~/~~/sdmx.org/>>https://http:sdmx.org]].
20 +* Guidelines for the development, maintenance, and governance of metadata structure definitions (MSDs) will be made available separately under “Guidelines” at [[http:~~/~~/sdmx.org/>>https://http:sdmx.org]].
21 +* Documentation on more IT-related issues is available at the SDMX IT tools and SDMX tutorials site at [[http:~~/~~/sdmx.org/?page_id=13>>https://http:sdmx.org?page_id=13]]. The SDMX Tools Repository can be accessed at [[http:~~/~~/www.sdmxtools.org/.>>https://http:www.sdmxtools.org.WebHome]] Many of the SDMX tools listed and described there are available free of charge.
22 22  
23 23  This document is structured as follows. Section 2 outlines general design principles of DSDs. Section 3 discusses different usage contexts of DSDs in more detail. Section 4 gives an overview of different data structuring approaches including benefits, drawbacks, and contextspecific recommendations. General minimum structural and semantic requirements are discussed in section 5. Section 6 provides a step-by-step guide to designing DSDs including a checklist for DSD designers. The three annexes include a glossary in Annex 1, a definition and brief introduction of the core components of a DSD in Annex 2, and a list of references in Annex 3.
24 24  
25 25  = 2 GENERAL DESIGN PRINCIPLES =
26 26  
27 -Besides the evident requirement of //standard compliance//, a couple of general design principles apply to SDMX DSD development independently of the domain and the particular usage context the DSD is embedded in. Examples include //flexibility in changing requirements//; //stability//; //usage of existing// code lists or even DSDs; and //parsimony//, //simplicity//, //unambiguousness//, and //density// of the dimensional model. Please note that the SDMX-ML Standards do not impose an order on concepts (i.e., dimensions and attributes). Strictly speaking, standard compliance of a DSD only entails technical compliance with the SDMX technical standard. However, //adherence to// SDMX content recommendations, principles, and best practices as provided in the //SDMX Content-Oriented Guidelines// (see http:~/~/sdmx.org/?page_id=11) is strongly recommended. It should be kept in mind that one major aim of SDMX is to have transparency and agreement on the meaning of statistical concepts in order to allow their flawless communication.
27 +Besides the evident requirement of //standard compliance//, a couple of general design principles apply to SDMX DSD development independently of the domain and the particular usage context the DSD is embedded in. Examples include //flexibility in changing requirements//; //stability//; //usage of existing// code lists or even DSDs; and //parsimony//, //simplicity//, //unambiguousness//, and //density// of the dimensional model. Please note that the SDMX-ML Standards do not impose an order on concepts (i.e., dimensions and attributes). Strictly speaking, standard compliance of a DSD only entails technical compliance with the SDMX technical standard. However, //adherence to// SDMX content recommendations, principles, and best practices as provided in the //SDMX Content-Oriented Guidelines// (see [[http:~~/~~/sdmx.org/?page_id=11>>https://http:sdmx.org?page_id=11]]) is strongly recommended. It should be kept in mind that one major aim of SDMX is to have transparency and agreement on the meaning of statistical concepts in order to allow their flawless communication.
28 28  
29 29  == 2.1 Reuse of existing DSDs and code lists ==
30 30  
... ... @@ -61,7 +61,7 @@
61 61  
62 62  === 2.1.3 Suitability of available DSDs and code lists ===
63 63  
64 -In case an existing DSD is close to but differs from what is needed, it may: (i) contain irrelevant concepts, (ii) lack some required concepts, (iii) use the concepts in different roles than required, (iv) deviate with respect to some of the code lists, or (v) contain pure dimensions when mixed dimensions would make more sense or vice versa. More complex situations that are combinations of several (or even all) of these five cases may occur as well. For example, an existing DSD could contain unnecessary concepts and lack other concepts at the same time.
64 +In case an existing DSD is close to but differs from what is needed, it may: {{{(i)}}} contain irrelevant concepts, (ii) lack some required concepts, (iii) use the concepts in different roles than required, (iv) deviate with respect to some of the code lists, or (v) contain pure dimensions when mixed dimensions would make more sense or vice versa. More complex situations that are combinations of several (or even all) of these five cases may occur as well. For example, an existing DSD could contain unnecessary concepts and lack other concepts at the same time.
65 65  
66 66  ==== 2.1.3.1 Irrelevant concepts ====
67 67  
... ... @@ -243,7 +243,7 @@
243 243  
244 244  The decision on content and number of concepts in a DSD usually leads to the question of how far the “//indicator//” dimension should be decomposed. There are some (cross-domain) concepts, such as geographical and temporal reference and unit of measure, that are relevant in most DSDs. Once those are defined (the usage of the SDMX COG is highly recommended!) the actual “//subject-matter//” or “//domain//” concepts remain. One option is to combine all those concepts into one “indicator” dimension which may make sense in certain scenarios, for example for smaller single-domain, single-purpose DSDs with few or no crossclassifications or for display in an end-user dissemination tool. The other extreme strategy is to decompose into as many components as possible by splitting any breakdown concepts from the core indicator concept.
245 245  
246 -The range of options between the “//just one//”// //(mixed) and “//all component//” subject-matter dimensions approaches is subject to the comprehensiveness (i.e. size, coverage) of the data exchange that the DSD is being developed for. If using a “mixed dimensions” approach, rules for the composition of the mixed dimension(s) may be specified (e.g. concatenate concepts A, B, and C to get mixed dimension X), allowing their easy re-decomposition. In general composite dimensions should be avoided as previously recommended by the SDMX Technical Notes, but there are cases that suggest the usage of composite dimensions. Table 4 juxtaposes general pros and cons of the “//many pure concepts//” and “//fewer composite concepts//” approaches.
246 +The range of options between the “//just one//” (mixed) and “//all component//” subject-matter dimensions approaches is subject to the comprehensiveness (i.e. size, coverage) of the data exchange that the DSD is being developed for. If using a “mixed dimensions” approach, rules for the composition of the mixed dimension(s) may be specified (e.g. concatenate concepts A, B, and C to get mixed dimension X), allowing their easy re-decomposition. In general composite dimensions should be avoided as previously recommended by the SDMX Technical Notes, but there are cases that suggest the usage of composite dimensions. Table 4 juxtaposes general pros and cons of the “//many pure concepts//” and “//fewer composite concepts//” approaches.
247 247  
248 248  **Table 4. General comparison of data structuring approaches**
249 249  
... ... @@ -315,7 +315,7 @@
315 315  
316 316  The “one DSD” approach works best for single-domain and/or single-purpose scenarios. In more complex scenarios, more complex approaches are more suitable. Usage of the “one DSD” approach in a multi-domain or multi-purpose scenario actually means that one master DSD containing all concepts, code lists, and codes relevant in any (but most likely not all) domains and/or purposes is used by all domains and/or purposes without constraints. If a “many pure concepts” approach is used, the DSD will be sparse and require many “not applicable” values or structure maps.
317 317  
318 -In those more complex scenarios, multi-DSD approaches have more potential. The “master DSD + satellite DSDs” approach imposes more restrictions and aims at a higher degree of content harmonization than the more loosely coupled (or even independent) multi-DSD approach. While the former specifies the concepts and code lists to be used by all derived DSDs, the latter is more flexible. Therefore, the master + satellites approach is suggested for data exchange scenarios with a high degree of harmonization / standardization required such as at the international level or between national and international organizations. Please note that what is termed “master DSD + satellite DSDs” approach here may also be implemented as master DSD plus constrained data flows with or without using structure maps.
318 +In those more complex scenarios, multi-DSD approaches have more potential. The “master DSD + satellite DSDs” approach imposes more restrictions and aims at a higher degree of content harmonization than the more loosely coupled (or even independent) multi-DSD approach. While the former specifies the concepts and code lists to be used by all derived DSDs, the latter is more flexible. Therefore, the master + satellites approach is suggested for data exchange scenarios with a high degree of harmonization/standardization required such as at the international level or between national and international organizations. Please note that what is termed “master DSD + satellite DSDs” approach here may also be implemented as master DSD plus constrained data flows with or without using structure maps.
319 319  
320 320  Even in the multiple independent DSDs approach, sharing of concepts and code lists by reference is recommended. This may be problematic if additional codes are needed by certain DSDs, as neither the addition of codes to a code list used by reference nor the concatenation of multiple code lists included by reference is supported by the current SDMX Technical Standards. The only way of implementing “combined” code lists by reference is to reference each single code from each relevant partial code list.
321 321  
... ... @@ -332,7 +332,7 @@
332 332  )))|(% colspan="2" %)use if harmonization is important in covered domains or purposes or if such a set of DSDs is already available at international level|easier to do than master + satellite approach each domain/purpose can maintain DSDs independently can be created on the fly from structured databases
333 333  |**between national organizations**|(% colspan="4" %)the same applies as to the “within organization” scenario
334 334  |**between int. organization and national organizations**|(% colspan="2" %)best for single domain, single purpose scenarios that are usually rather restricted with very clear specification of what needs to be exchanged|preferable over multiDSD approach in case of multi-domain and/or multi-purpose scenarios with highly correlated data flows for maintenance reasons|(((
335 -for multi-domain and/or multipurpose scenarios; only recommended if overlap of domains/purposes is minor (e.g. just w.r.t. cross-domain concepts) equivalent to multiple “one DSD” solutions, one for each domain / purpose
335 +for multi-domain and/or multipurpose scenarios; only recommended if overlap of domains/purposes is minor (e.g. just w.r.t. cross-domain concepts) equivalent to multiple “one DSD” solutions, one for each domain/purpose
336 336  )))
337 337  |**between international organizations**|(% colspan="3" %)comparable to “national to international” scenario|
338 338  |**dissemination to public**|(% colspan="2" %)for single-domain, single-purpose cases in more complex cases this may be the preferable approach for data discovery tools (one data structure to find and access all data)|(% colspan="2" %)(((
... ... @@ -340,7 +340,7 @@
340 340  
341 341  * if it is relevant for the public to see the relationship between the data structures: use master + satellites approach
342 342  * otherwise the multi-DSD option is preferable, although with the highest possible degree of re-use of code lists and concepts
343 -* in both cases: important to include only concepts, code lists, and codes actually available / used by the data
343 +* in both cases: important to include only concepts, code lists, and codes actually available/used by the data
344 344  )))
345 345  
346 346  In general, finding the “perfect” data structure is less important for bilateral data exchange. Independent, custom-tailored DSDs may do the job quite well, as harmonization and standardization are typically not of high importance. If the data exchange is just a part of a more comprehensive scenario (e.g. multi-purpose, multi-domain, gateway, or data-sharing scenarios), a master DSD with satellite DSDs is preferable.
... ... @@ -367,7 +367,7 @@
367 367  
368 368  Certain concepts can be broadly agreed upon as being relevant in any data exchange, although their roles may differ between scenarios. The SDMX Content-Oriented Guidelines define many of these cross-domain concepts and, thus, should be referred to for further details on their specification.
369 369  
370 -In general, multi-purpose and multi-domain scenarios may require more concepts than single-purpose and/or –domain scenarios. This mainly applies to subject-matter (or domainspecific) concepts and concepts that inform about the data source, provider, or process.
370 +In general, multi-purpose and multi-domain scenarios may require more concepts than single-purpose and/or – domain scenarios. This mainly applies to subject-matter (or domainspecific) concepts and concepts that inform about the data source, provider, or process.
371 371  
372 372  Exchanges between organizations, especially on an international level, typically require more concepts to cover context information, as data are transferred out of their usual context, meaning that users in the new context do not have the same knowledge of the data and may need additional background information. For exchanges of data within an organization, some context information may be common (implicit) knowledge so that it does not need to be made explicit in the data structure.
373 373  
... ... @@ -389,19 +389,20 @@
389 389  
390 390  **Table 9. Minimum requirements for DSDs~*~***
391 391  
392 -|(% style="width:205px" %)**Question**|(% style="width:272px" %)**Concept**|(% style="width:178px" %)**COG**|(% style="width:270px" %)**Code list**|(% style="width:690px" %)**Time series Cross-section**
393 -|(% style="width:205px" %)Where?|(% style="width:272px" %)reference area|(% style="width:178px" %)X|(% style="width:270px" %)revision|(% style="width:690px" %)mand. attribute or dimension
394 -|(% style="width:205px" %)What?|(% style="width:272px" %)“indicator”|(% style="width:178px" %)-|(% style="width:270px" %)domain|(% style="width:690px" %)one or multiple dimensions
395 -|(% style="width:205px" %)How?|(% style="width:272px" %)unit of measure|(% style="width:178px" %)X|(% style="width:270px" %)development|(% style="width:690px" %)mand. attribute or dimension
396 -|(% style="width:205px" %)How?|(% style="width:272px" %)unit multiplier|(% style="width:178px" %)X|(% style="width:270px" %)available|(% style="width:690px" %)mandatory attribute
397 -|(% style="width:205px" %)How?|(% style="width:272px" %)decimals|(% style="width:178px" %)X|(% style="width:270px" %)available|(% style="width:690px" %)mandatory attribute
398 -|(% style="width:205px" %)How?|(% style="width:272px" %)//adjustment//|(% style="width:178px" %)X|(% style="width:270px" %)development|(% style="width:690px" %)mand. att. not relevant
399 -|(% style="width:205px" %)When?|(% style="width:272px" %)time period|(% style="width:178px" %)X|(% style="width:270px" %)format|(% style="width:690px" %)dimension mand. att.
400 -|(% style="width:205px" %)When?|(% style="width:272px" %)time format|(% style="width:178px" %)X|(% style="width:270px" %)available|(% style="width:690px" %)mandatory attribute
401 -|(% style="width:205px" %)When?|(% style="width:272px" %)time period – collection|(% style="width:178px" %)X|(% style="width:270px" %)development|(% style="width:690px" %)mand. att. cond. att.
402 -|(% style="width:205px" %)When?|(% style="width:272px" %)data update – last update|(% style="width:178px" %)X|(% style="width:270px" %)time stamp|(% style="width:690px" %)mandatory attribute
403 -|(% style="width:205px" %)How often?|(% style="width:272px" %)//frequency//|(% style="width:178px" %)X|(% style="width:270px" %)available|(% style="width:690px" %)mand. att. or not relevant
404 -|(% colspan="2" style="width:477px" %)How much? observation value|(% style="width:178px" %)-|(% style="width:270px" %)numeric|(% style="width:690px" %)dimension measure
392 +(% style="width:1308.83px" %)
393 +|(% style="width:205px" %)**Question**|(% style="width:272px" %)**Concept**|(% style="width:178px" %)**COG**|(% style="width:270px" %)**Code list**|(% style="width:290px" %)**Time series**|(% style="width:221px" %)**Cross-section**
394 +|(% style="width:205px" %)Where?|(% style="width:272px" %)reference area|(% style="width:178px" %)X|(% style="width:270px" %)revision|(% colspan="2" rowspan="1" style="width:478px" %)mand. attribute or dimension
395 +|(% style="width:205px" %)What?|(% style="width:272px" %)“indicator”|(% style="width:178px" %)-|(% style="width:270px" %)domain|(% colspan="2" rowspan="1" style="width:478px" %)one or multiple dimensions
396 +|(% style="width:205px" %)How?|(% style="width:272px" %)unit of measure|(% style="width:178px" %)X|(% style="width:270px" %)development|(% colspan="2" rowspan="1" style="width:478px" %)mand. attribute or dimension
397 +|(% style="width:205px" %)How?|(% style="width:272px" %)unit multiplier|(% style="width:178px" %)X|(% style="width:270px" %)available|(% colspan="2" rowspan="1" style="width:478px" %)mandatory attribute
398 +|(% style="width:205px" %)How?|(% style="width:272px" %)decimals|(% style="width:178px" %)X|(% style="width:270px" %)available|(% colspan="2" rowspan="1" style="width:478px" %)mandatory attribute
399 +|(% style="width:205px" %)How?|(% style="width:272px" %)//adjustment//|(% style="width:178px" %)X|(% style="width:270px" %)development|(% style="width:290px" %)mand. att.|(% style="width:221px" %) not relevant
400 +|(% style="width:205px" %)When?|(% style="width:272px" %)time period|(% style="width:178px" %)X|(% style="width:270px" %)format|(% style="width:290px" %)dimension|(% style="width:221px" %)mand. att.
401 +|(% style="width:205px" %)When?|(% style="width:272px" %)time format|(% style="width:178px" %)X|(% style="width:270px" %)available|(% colspan="2" rowspan="1" style="width:478px" %)mandatory attribute
402 +|(% style="width:205px" %)When?|(% style="width:272px" %)time period – collection|(% style="width:178px" %)X|(% style="width:270px" %)development|(% style="width:290px" %)mand. att.|(% style="width:221px" %)cond. att.
403 +|(% style="width:205px" %)When?|(% style="width:272px" %)data update – last update|(% style="width:178px" %)X|(% style="width:270px" %)time stamp|(% colspan="2" rowspan="1" style="width:478px" %)mandatory attribute
404 +|(% style="width:205px" %)How often?|(% style="width:272px" %)//frequency//|(% style="width:178px" %)X|(% style="width:270px" %)available|(% style="width:290px" %)mand. att. or|(% style="width:221px" %)not relevant
405 +|(% style="width:205px" %)How much?|(% style="width:272px" %)observation value|(% style="width:178px" %)-|(% style="width:270px" %)numeric|(% colspan="2" rowspan="1" style="width:290px" %) measure
405 405  
406 406  ~*~*Concepts in //italics// are only relevant for time series DSDs. An “X” in the COG column means the concept is defined in the COG. Code list “development” means that the SWG will develop a code list to be recommended in the COG; “revision” means that the code list is recommended by the COG and under revision by the SWG; “format” means that a format is defined by another concept; “text”, “time stamp”, and “numeric” provide data types used for uncoded concepts.
407 407  
... ... @@ -411,7 +411,7 @@
411 411  
412 412  |**Question**|**Concept**|**COG**|**Code list**|**TS**|**CS**|**Scenario**
413 413  |Who?|compiling agency|X|development|(((
414 -conditional (sibling)
415 +conditional (sibling)
415 415  )))|conditional (obs. level)|data provider different from data compiler
416 416  |Who?|(((
417 417  confidentiality status – observation
... ... @@ -547,24 +547,30 @@
547 547  (% class="wikigeneratedid" %)
548 548  Figure 12. Possible attribute attachment levels
549 549  
551 +(% class="wikigeneratedid" %)
552 +[[image:1768470860119-204.png]]
550 550  
551 551  (% class="wikigeneratedid" id="HFigure13.Codelistspecificationprocess" %)
552 552  Figure 13. Code list specification process
553 553  
554 -
557 +(% class="wikigeneratedid" %)
555 555  Figure 14 recaps the priorities given to different types of existing code lists when searching for candidates for reuse (step 4.3.2.1.). Code lists recommended by the SDMX COG (and maintained by the SDMX consortium) are ranked the highest.
556 556  
560 +[[image:1768470878394-873.png]]
557 557  
558 558  (% class="wikigeneratedid" id="HFigure14.Priorityrankingofexistingcodelistsforreuse" %)
559 559  Figure 14. Priority ranking of existing code lists for reuse
560 560  
561 -
565 +(% class="wikigeneratedid" %)
562 562  Figure 15 summarizes the aspects to be considered in the evaluation of the suitability of existing code lists (step 4.3.2.2.). Figure 16 summarizes the scenarios of adapting existing code lists that do not fully meet the specified needs (step 4.3.2.3.2). For a detailed description of the cases of partial unsuitability see section 2.1. above.
563 563  
568 +[[image:1768470896763-366.png]]
564 564  
565 565  (% class="wikigeneratedid" id="HFigure15.Aspectsofcodelistsuitability" %)
566 566  Figure 15. Aspects of code list suitability
567 567  
573 +(% class="wikigeneratedid" %)
574 +[[image:1768470911321-123.png]]
568 568  
569 569  (% class="wikigeneratedid" id="HFigure16.Codelistmodificationscenarios" %)
570 570  Figure 16. Code list modification scenarios
... ... @@ -577,8 +577,11 @@
577 577  
578 578  Figure 17 provides an overview of all steps in the DSD design process as described in the previous subsections 1. to 3. Figure 18 compiles those steps into a checklist for DSD designers to help them make sure all aspects are considered.
579 579  
587 +[[image:1768471052577-528.png]]
588 +
580 580  Figure 17. DSD design process
581 581  
591 +[[image:1768470939545-136.png]]
582 582  
583 583  Figure 18. Checklist for DSD design process
584 584  
... ... @@ -604,7 +604,7 @@
604 604  
605 605  == 9.1 SDMX Documents ==
606 606  
607 -The SDMX documents referred to in these guidelines as well as the complete technical specification of the SDMX Technical Standard 2.1 (and earlier versions) are available online at http:~/~/sdmx.org/. The SDMX documents currently under development by the Statistical and Technical Working Groups will also be made available on the SDMX website.
617 +The SDMX documents referred to in these guidelines as well as the complete technical specification of the SDMX Technical Standard 2.1 (and earlier versions) are available online at [[http:~~/~~/sdmx.org/>>https://http:sdmx.org]]. The SDMX documents currently under development by the Statistical and Technical Working Groups will also be made available on the SDMX website.
608 608  
609 609  === 9.1.1 Existing documents ===
610 610  
... ... @@ -628,10 +628,12 @@
628 628  
629 629  == 9.2 Non-SDMX Documents ==
630 630  
631 -6th Edition of the IMF's Balance of Payments Manual (BPM6). Available online at http:~/~/www.imf.org/external/pubs/ft/bop/2007/bopman6.htm.
641 +6th Edition of the IMF's Balance of Payments Manual (BPM6). Available online at [[http:~~/~~/www.imf.org/external/pubs/ft/bop/2007/bopman6.htm>>https://http:www.imf.orgexternalpubsftbop2007bopman6.htm||rel="noopener noreferrer" target="_blank"]].
632 632  
633 -METIS: Generic Statistical Business Process Model (GSBPM). Available online at http:~/~/www1.unece.org/stat/platform/display/metis/The+Generic+Statistical+Business+Process+Model. UN's System of National Accounts Manual 2008 (SNA2008). Available online at http:~/~/unstats.un.org/unsd/nationalaccount/sna2008.asp.
643 +METIS: Generic Statistical Business Process Model (GSBPM). Available online at [[http:~~/~~/www1.unece.org/stat/platform/display/metis/The+Generic+Statistical+Business+Process+Model>>https://http:www1.unece.orgstatplatformdisplaymetisThe+Generic+Statistical+Business+Process+Model||rel="noopener noreferrer" target="_blank"]].
634 634  
645 +UN's System of National Accounts Manual 2008 (SNA2008). Available online at [[http:~~/~~/unstats.un.org/unsd/nationalaccount/sna2008.asp>>https://http:unstats.un.orgunsdnationalaccountsna2008.asp||rel="noopener noreferrer" target="_blank"]].
646 +
635 635  ----
636 636  
637 637  {{putFootnotes/}}
1768470860119-204.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.helena
Size
... ... @@ -1,0 +1,1 @@
1 +37.9 KB
Content
1768470878394-873.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.helena
Size
... ... @@ -1,0 +1,1 @@
1 +49.7 KB
Content
1768470896763-366.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.helena
Size
... ... @@ -1,0 +1,1 @@
1 +29.9 KB
Content
1768470911321-123.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.helena
Size
... ... @@ -1,0 +1,1 @@
1 +49.2 KB
Content
1768470939545-136.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.helena
Size
... ... @@ -1,0 +1,1 @@
1 +143.4 KB
Content
1768471052577-528.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.helena
Size
... ... @@ -1,0 +1,1 @@
1 +97.4 KB
Content
© Semantic R&D Group, 2026