Skip to Content
Last modified by Artur K. on 2026/05/29 14:28
From version 1.7
edited by Helena K.
on 2026/01/15 15:12
Change comment: There is no comment for this version
To version 1.10
edited by Helena K.
on 2026/01/15 15:15
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -88,8 +88,6 @@
88 88  |**Removal of one or more codes in the HCL or removal of one or more codes in the referenced code lists**|(% style="width:150px" %)**Major**: **+.0**|(% style="width:1045px" %)Data represented using the old HCL can no longer be represented using the new HCL, thus resulting in a break in backward compatibility
89 89  |**Addition, modification or removal of one or more hierarchical levels**|(% style="width:150px" %)**Major: +.0**|(% style="width:1045px" %)The reorganisation of codes within hierarchies has a significant impact on the code aggregations
90 90  
91 -
92 -
93 93  |(% colspan="3" %)**CONCEPT SCHEME (CS)**
94 94  |(% style="width:874px" %)**Type of change**|(% style="width:154px" %)**Impact**|(% style="width:1044px" %)**Comments**
95 95  |(% style="width:874px" %)**Addition of one or more new concepts in an existing CS**|(% style="width:154px" %)**Minor**: **N.+**|(% style="width:1044px" %)(((
... ... @@ -97,18 +97,16 @@
97 97  )))
98 98  |(% style="width:874px" %)**Removal of one or more existing concepts**|(% style="width:154px" %)**Major: +.0**|(% style="width:1044px" %)Data exchanged/disseminated using the old version of the CS can no longer be exchanged/disseminated using the new version with less concepts
99 99  
100 -
101 -
102 102  |(% colspan="3" %)**DATA STRUCTURE DEFINITION (DSD)**
103 -|**Type of change**|**Impact**|**Comments**
104 -|**Addition of a dimension**|**Major**: **+.0**|Adding a new dimension has a strong impact because a dimension represents the identifier of a dataset, thus requiring a remodelling of the data as existing structural validation will fail
105 -|**Addition of a mandatory attribute**|**Major**: **+.0**|If the attribute is mandatory, the situation is the same as under point “Addition of a dimension”
106 -|**Addition of a conditional attribute**|**Minor**: **N.+**|If the attribute is conditional backward compatibility is maintained
107 -|**Removal of a dimension or attribute**|**Major**: **+.0**|Whatever the type of component, the change does not guarantee backward compatibility
99 +|(% style="width:868px" %)**Type of change**|(% style="width:159px" %)**Impact**|(% style="width:1045px" %)**Comments**
100 +|(% style="width:868px" %)**Addition of a dimension**|(% style="width:159px" %)**Major**: **+.0**|(% style="width:1045px" %)Adding a new dimension has a strong impact because a dimension represents the identifier of a dataset, thus requiring a remodelling of the data as existing structural validation will fail
101 +|(% style="width:868px" %)**Addition of a mandatory attribute**|(% style="width:159px" %)**Major**: **+.0**|(% style="width:1045px" %)If the attribute is mandatory, the situation is the same as under point “Addition of a dimension”
102 +|(% style="width:868px" %)**Addition of a conditional attribute**|(% style="width:159px" %)**Minor**: **N.+**|(% style="width:1045px" %)If the attribute is conditional backward compatibility is maintained
103 +|(% style="width:868px" %)**Removal of a dimension or attribute**|(% style="width:159px" %)**Major**: **+.0**|(% style="width:1045px" %)Whatever the type of component, the change does not guarantee backward compatibility
108 108  
109 109  For concrete examples, see the Appendix.
110 110  
111 -=== 5. How versioning works for inter-dependent artefacts ===
107 += 5. How versioning works for inter-dependent artefacts =
112 112  
113 113  This section describes how version changes to inter-dependent or parent/child artefacts affect each other. For example, how a Concept Scheme is affected when one of the Code Lists that it references changes version.
114 114  
... ... @@ -131,51 +131,40 @@
131 131  The replacement of a reference with a different reference has the same impact for every artefact.
132 132  
133 133  |(% colspan="3" %)**ALL ARTEFACTS**
134 -|**Type of change**|**Impact**|**Comments**
135 -|(((
136 -**Replacement of a child artefact having a different version, but same id and**
137 -
138 -**Agency**
130 +|(% style="width:492px" %)**Type of change**|(% style="width:441px" %)**Impact**|**Comments**
131 +|(% style="width:492px" %)(((
132 +**Replacement of a child artefact having a different version, but same id and Agency**
133 +)))|(% style="width:441px" %)(((
134 +**The child artefact version change is replicated in the parent artefact**
139 139  )))|(((
140 -**The child artefact version change is replicated in the**
141 -
142 -**parent artefact**
143 -)))|(((
144 144  If a child artefact (e.g. a Code List) has a minor version change, then the parent artefact (e.g. a Concept Scheme) should also have a minor version change.
145 -
146 146  If there are several child artefact version changes, the most severe impact is replicated in the parent artefact. For example, if two Code Lists have minor changes, and one Code List has a major change at the same time, the parent Concept Scheme has a major version change
147 147  )))
148 -|(((
149 -**Replacement of a referenced child artefact having a**
139 +|(% style="width:492px" %)(((
140 +**Replacement of a referenced child artefact having a different id or Agency**
141 +)))|(% style="width:441px" %)**The parent artefact version impact depends on the backward/ forward compatibility as shown in the tables above**|Technically, the child artefact is not considered to be related to the previous child artefact. It needs to be checked whether exchange contracts can still be guaranteed (backward/forward compatibility principle)
150 150  
151 -**different id or Agency**
152 -)))|**The parent artefact version impact depends on the backward/ forward compatibility as shown in the tables above**|Technically, the child artefact is not considered to be related to the previous child artefact. It needs to be checked whether exchange contracts can still be guaranteed (backward/forward compatibility principle)
153 -
154 154  ==== b. Addition or removal of referenced artefacts ====
155 155  
156 -| |(% colspan="2" %)**CONCEPT SCHEME (CS)**
157 -|**Type of change**|**Impact**|**Comments**
158 -|(((
159 -**Addition or removal of a child**
145 +|(% colspan="3" style="width:876px" %)**CONCEPT SCHEME (CS)**
146 +|(% style="width:845px" %)**Type of change**|(% style="width:156px" %)**Impact**|(% style="width:1071px" %)**Comments**
147 +|(% style="width:845px" %)(((
148 +**Addition or removal of a child Code List**
149 +)))|(% style="width:156px" %)**Minor: N.+**|(% style="width:1071px" %)The child Code Lists in a Data Structure Definition have priority over those referenced in a Concept Scheme. Child Code Lists added to or removed from a Concept Scheme do not have a direct impact on the data exchange. Backward/forward compatibility depends on the way Code Lists are referenced in Data Structure Definitions referencing the concept scheme. This needs to be taken into account when creating a new version of a DSD accordingly
160 160  
161 -**Code List**
162 -)))|**Minor: N.+**|The child Code Lists in a Data Structure Definition have priority over those referenced in a Concept Scheme. Child Code Lists added to or removed from a Concept Scheme do not have a direct impact on the data exchange. Backward/forward compatibility depends on the way Code Lists are referenced in Data Structure Definitions referencing the concept scheme. This needs to be taken into account when creating a new version of a DSD accordingly
163 163  
164 164  
165 -
166 -| |(% colspan="2" %)**DATA STRUCTURE DEFINITION (DSD)**
153 +|(% colspan="3" %)**DATA STRUCTURE DEFINITION (DSD)**
167 167  |**Type of change**|**Impact**|**Comments**
168 168  |**Addition or removal of a child Code List**|(((
169 -**If same id and Agency, then the child artefact version change is replicated in the parent artefact.**
170 -
171 -**If different id or Agency, impact wil depend on the backward/forward compatibility as shown in the tables above**
156 +**If same id and Agency, then the child artefact version change is replicated in the parent artefact.
157 +If different id or Agency, impact wil depend on the backward/forward compatibility as shown in the tables above**
172 172  )))|(((
173 173  If a child Code List has a minor version change, then the DSD should also have a minor version change.
174 -
175 175  If there are several Code List version changes, the most severe impact is replicated in the DSD. For example, if two Code Lists have minor changes, and one Code List has a major change at the same time, the parent DSD has a major version change
176 176  )))
177 177  
178 -=== 6. Appendix - Examples ===
163 += 6. Appendix - Examples =
179 179  
180 180  **Example 1 – Change to a Code List name, for clarification purposes**. **Patch Impact: N.M.+**
181 181  
... ... @@ -197,10 +197,8 @@
197 197  |(% colspan="2" %)**AGGREGATION OF EXISTING CODES**
198 198  |**Old version**|**New version**
199 199  |**2011** Heifers (female bovine that never calved), live **2012** Cows, live|**2010** Heifers and cows, live
200 -|(% colspan="2" %)Codes **2011** and **2012** are fully{{footnote}}i.e. without integration into or combination with another existing code.{{/footnote}} **removed** and replaced with one **brand new** code. In this case there is a many to 1 correspondence between the codes.
185 +|(% colspan="2" %)Codes **2011** and **2012** are fully{{footnote}}i.e. without integration into or combination with another existing code.{{/footnote}} __**removed**__ and replaced with one __**brand new**__ code. In this case there is a many to 1 correspondence between the codes.
201 201  
202 -
203 -
204 204  |(% colspan="2" %)**DISAGGREGATION OF EXISTING CODES**
205 205  |**Old version**|**New version**
206 206  |**1010** Live horses|(((
... ... @@ -207,10 +207,8 @@
207 207  1. Pure bred breeding horses, live
208 208  1. Other horses, live
209 209  )))
210 -|(% colspan="2" %)Code **1010** is fully **removed** and replaced with two **brand new** codes. In this case there is a 1 to m correspondence between the codes.
193 +|(% colspan="2" %)Code __**1010**__ is fully __**removed**__ and replaced with two __**brand new**__ codes. In this case there is a 1 to m correspondence between the codes.
211 211  
212 -
213 -
214 214  |(% colspan="2" %)**REORGANISATION OF EXISTING CODES**
215 215  |**Old version**|**New version**
216 216  |(((
... ... @@ -240,17 +240,17 @@
240 240  |(% colspan="2" %)**ADDING A NEW CODE IN AN EXISTING HIERARCHY – HIERARCHICAL CODE LIST**
241 241  |**Old version**|**New version**
242 242  |(((
243 -• A1 - World (codelist ref. ECB@CL_AREAS@1.0) o E1 - Europe (ECB@CL_COUNTRIES@1.0)
224 + A1 - World (codelist ref. ECB@CL_AREAS@1.0) o E1 - Europe (ECB@CL_COUNTRIES@1.0)
244 244  
245 - ES - Spain FR - France
226 +ES - Spain FR - France
246 246  
247 247  GR - Greece
248 248  
249 249  IT - Italy o E4 - Africaetc.
250 250  )))|(((
251 -• A1=World (codelist ref. ECB@CL_AREAS@1.0) o E1 =Europe (ECB@CL_COUNTRIES@1.0)
232 +A1=World (codelist ref. ECB@CL_AREAS@1.0) o E1 =Europe (ECB@CL_COUNTRIES@1.0)
252 252  
253 - ES = Spain FR = FranceGR = Greece
234 +ES = Spain FR = FranceGR = Greece
254 254  
255 255  IT = Italy
256 256  
© Semantic R&D Group, 2026