Skip to Content
Last modified by Artur K. on 2026/05/29 14:28
From version 2.1
edited by Helena K.
on 2026/01/16 16:24
Change comment: There is no comment for this version
To version 1.1
edited by Helena K.
on 2026/01/16 16:22
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -1,15 +1,15 @@
1 -{{box title="**Contents**"}}
2 -{{toc/}}
3 -{{/box}}
1 +
4 4  
5 -= Document History =
3 +**Document History**
6 6  
7 7  |**Version**|**Date**|**Comment**
8 8  |1.0|1/10/2014|Initial version
9 9  |2.0|1/5/2019|Guideline title change (more accurate); add new OBS_STATUS codes to hierarchy; changed 3.1 approach to include OBS_STATUS code (this compatibility break is the major version change); text clarification; include a document history
10 10  
11 -= 1) Introduction =
12 12  
10 +
11 +**1) Introduction**
12 +
13 13  First of all, it is important to note that the "Observation status" code list (CL_OBS_STATUS{{footnote}}https://sdmx.org/?page_id=3215{{/footnote}}) has an heterogeneous character as it mixes concepts which are not always mutually exclusive (e.g. a missing value can generate a break in time series, an estimated value can be of low reliability). Thus, to cope with the issue of allocating more than one flag to one statistical value, this code list should ideally be broken down into various sub-code lists corresponding to the various concepts covered. It was not done so because it was felt that it would unnecessarily increase the number of (very short) code lists for low benefits in terms of technical and conceptual orthodoxy.
14 14  
15 15  However, in view of the central importance of this code list, it is essential to provide implementers with all possible ways of implementing this code list so that they can decide, based on their specific implementation needs, which option best suits their requirements. These various options are presented in the sections below, and their pros and contras explicated.
... ... @@ -18,7 +18,7 @@
18 18  
19 19  The SDMX standard allows for the use of zero or more observation level attributes, using any identifiers. However, SDMX-EDI imposes the mandatory use of the observation level attribute called OBS_STATUS. In the past, SDMX-EDI has limited itself, for practical reasons, to the use of the observation level attributes OBS_STATUS, CONF_STATUS, PRE_BREAK_VALUE and COMMENT_OBS, but SDMX-EDI can handle any number of observation level attributes, as long as OBS_STATUS is included.
20 20  
21 -= 2) One flag only per value =
21 +**2) One flag only per value**
22 22  
23 23  In case implementers want to use only one single flag per value, they should use the hierarchy below to determine the code to be used. This approach (choice of only one event, namely the most important one) offers a good compromise between simplicity for the user, completeness of provided information and presentational easiness of management on the user interface side. The main drawback of this approach is the loss of information resulting from the use of only one flag when several flags may apply to a given value.
24 24  
... ... @@ -47,7 +47,7 @@
47 47  |**G** / experimental value|Yes|
48 48  |**A** / normal value|Yes|
49 49  
50 -= 3) Multiple flagging =
50 +**3) Multiple flagging**
51 51  
52 52  There might be cases however where implementers will want to attach multiple flags to one statistical value. To cope with this situation, three solutions have been analysed, based on:
53 53  
... ... @@ -57,7 +57,7 @@
57 57  
58 58  Technically the three approaches are possible. However, considering the severe limitations that the third approach would implicate, only one of the first two approaches will be recommended for use (as said earlier also with a view to improving harmonisation across implementations and backwards compatibility).
59 59  
60 -== 3.1) Duplication approach (recommended solution) ==
60 +**//3.1) Duplication approach (recommended solution)//**
61 61  
62 62  In this case, the OBS_STATUS concept is duplicated as many times as needed. These duplicated concepts should be named "OBS_STATUS", "OBS_STATUS_1", "OBS_STATUS_2", "OBS_STATUS_3", etc. All these concepts have to be inserted in the DSD and linked to the CL_OBS_STATUS code list. Only one value is allowed per code list. In order to have backwards compatibility with systems only processing a single observation status flag and also to keep DSDs with multiple flags compatible with DSDs using a single flag, it is strongly recommended to sort the flags according to the observation status hierarchy table above in a data message. For example, if the multiple flags should be G (experimental), V (unvalidated) and D (definition differs), then the order according to the hierarchy would be: OBS_STATUS = D, OBS_STATUS_1 = V, OBS_STATUS_2 = G. A system only parsing a single flag could still rely on the OBS_STATUS concept identifier to catch the flag with the highest priority.
63 63  
... ... @@ -67,7 +67,7 @@
67 67  
68 68  This approach is the recommended general solution for implementations where multiple flagging is required.
69 69  
70 -== 3.2) Decomposition approach (recommended solution if exchange does not support SDMX-EDI) ==
70 +**//3.2) Decomposition approach (recommended solution if exchange does not support SDMX-EDI)//**
71 71  
72 72  Here, CL_OBS_STATUS code list is broken down into its basic components, distinguished on the basis of the different concepts used and their mutually exclusive character. The list of "building blocks" composing the CL_OBS_STATUS code list as it stands at present could be represented as separate concepts as follows:
73 73  
... ... @@ -99,8 +99,10 @@
99 99  //This document recommends the "Duplication" approach mainly on the practical grounds of ease of implementation because its use of “OBS_STATUS” is compatible with the cross-domain concept scheme, whereas the Decomposition approach is not. The recommended approach could be reconsidered in the future, would the technical standard better accommodate the //decomposition //approach.//
100 100  )))
101 101  
102 -== 3.3) Extended single code list approach (strongly discouraged) ==
103 103  
103 +
104 +**//3.3) Extended single code list approach (strongly discouraged)//**
105 +
104 104  The extended version of CL_OBS_STATUS (see below) provides the full list of logically possible combinations of codes in a specific SDMX implementation.
105 105  
106 106  An advantage of this solution would be that only meaningful combinations of flags are included in the list. Users would not be able to choose combinations which would not make sense (such as "missing" and "estimated").
... ... @@ -132,7 +132,7 @@
132 132  
133 133  Considering the severe limitations implied by the third approach, only the first two approaches are recommended for use.
134 134  
135 -= 4) Conclusion =
137 +**4) Conclusion**
136 136  
137 137  From the analysis of the various approaches presented above, it appears clearly that the extended single code list approach cannot be recommended for use.
138 138  
... ... @@ -148,6 +148,7 @@
148 148  * **Recommended solution if exchange does not support SDMX-EDI**
149 149  * **Strongly discouraged**
150 150  
151 -----
152 152  
154 +
155 +
153 153  {{putFootnotes/}}
© Semantic R&D Group, 2026