Changes for page Guidelines on the Versioning of SDMX Artefacts

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -35,7 +35,7 @@
35	35
36	36	The criterion for deciding which component is impacted is the severity of the change, i.e. the possibility of maintaining backward and forward compatibility between the different versions of an artefact.
37	37
38		-== a. Description of backward/forward compatibility ==
	38	+==== a. Description of backward/forward compatibility ====
39	39
40	40	Backward compatibility is defined as: An item (e.g. a data message) that was produced and validated with the previous version of an artefact (e.g. a DSD) can still be successfully validated using the newest version of the same artefact. For example, a data message produced and validated with a DSD version 1.1 is still valid against the same DSD (same id and Agency) upgraded to version 1.2.
41	41
...	...	@@ -47,64 +47,71 @@
47	47	* MINOR version when changes are backward but not forward compatible;
48	48	* PATCH version when minor changes (e.g. text clarifications, correction of typos) are both backward and forward compatible.
49	49
50		-== **// //**b. Cost-benefit analysis for a major version change ==
	50	+**// //**b. Cost-benefit analysis for a major version change
51	51
52	52	The cost of imposing a “major” change should be balanced against the benefit of retaining backward compatibility, for example by not deleting codes used in existing data exchanges or by deleting or replacing codes only through a concerted effort of all data exchange partners.
53	53
54		-== c. Synthesis based on the above syntax and criterion ==
	54	+| |**//c. Synthesis based on the above syntax and criterion//**|
	55	+|(% colspan="2" %)**Change SeverityVersion ImpactDescription**|**Example**
	56	+|(% colspan="2" %)**Major +.0 Neither** backward **nor** forward compatibility|**1.2 2.0**
	57	+|(% colspan="2" %)**Minor N.+ **Backward **but not** forward compatibility|**1.0 1.1**
	58	+|(% colspan="2" %)**Patch N.M.+ **Backward **and** forward compatibility|**1.2 1.2.1**
55	55
56		-|(% colspan="2" %)**Change Severity**|**Version Impact**|**Description**|**Example**
57		-|(% colspan="2" %)**Major**|**+.0**|__**Neither**__ backward __**nor**__ forward compatibility|**1.2 **→**2.0**
58		-|(% colspan="2" %)**Minor**|**N.+**|Backward __**but not**__ forward compatibility|**1.0 **→**1.1**
59		-|(% colspan="2" %)**Patch**|**N.M.+**|Backward __**and**__ forward compatibility|**1.2 1.**→**2.1**
60		-
61	61	=== 4. Types of artefact changes and their versioning impact ===
62	62
63	63	As a general rule insignificant changes (e.g. textual clarifications or typos) will result in an increment of the patch component of the versioning system (i.e. N.M.**+**).
64	64
65		-|(% colspan="3" %)**CODE LIST (CL)**
66		-|(% style="width:877px" %)**Type of Change**|(% style="width:161px" %)**Impact**|(% style="width:1034px" %)**Comments**
67		-|(% style="width:877px" %)(((
	64	+| |(% colspan="2" %)**CODE LIST (CL)**
	65	+|**Type of Change**|**Impact**|**Comments**
	66	+|(((
68	68	**Addition into an existing CL of one or more new codes not having the**
69	69
70	70	**CodeList:Code:ParentCode attribute**
71		-)))|(% style="width:161px" %)**Minor**: **N.,,+,,**^^({{footnote}}The overall impact on compatibility should be assessed when there are several “minor” version impact changes. For example, it may be that the effect of adding several new Code List or HCL codes results in an implicit change in the meaning of existing Code List or HCL codes which may not be completely backward compatible, therefore (depending on the analysis) the overall version impact may be “Major +.0”.{{/footnote}})^^|(% style="width:1034px" %)Data exchanged/disseminated using the old CL can still be exchanged/disseminated using the new CL
72		-|(% style="width:877px" %)(((
	70	+)))|**Minor**: **N.,,+,,**^^({{footnote}}The overall impact on compatibility should be assessed when there are several “minor” version impact changes. For example, it may be that the effect of adding several new Code List or HCL codes results in an implicit change in the meaning of existing Code List or HCL codes which may not be completely backward compatible, therefore (depending on the analysis) the overall version impact may be “Major +.0”.{{/footnote}})^^|Data exchanged/disseminated using the old CL can still be exchanged/disseminated using the new CL
	71	+|(((
73	73	**Addition of one or more new hierarchies represented using the**
74	74
75	75	**CodeList:Code:ParentCode attribute (not using the Hierarchical Code List artefact)**
76		-)))|(% style="width:161px" %)**Minor**: **N.,,+,,^^(^^**^^{{footnote}}The overall impact on compatibility should be assessed when there are several “minor” version impact changes. For example, it may be that the effect of adding several new Code List or HCL codes results in an implicit change in the meaning of existing Code List or HCL codes which may not be completely backward compatible, therefore (depending on the analysis) the overall version impact may be “Major +.0”.{{/footnote}})^^|(% style="width:1034px" %)Data exchanged/disseminated using the old CL can still be exchanged/disseminated using the new CL as already existing hierarchies still represent the same aggregations
77		-|(% style="width:877px" %)**Addition of one or more new codes into existing hierarchies represented using the CodeList:Code:ParentCode attribute (not using the Hierarchical Code List artefact)**|(% style="width:161px" %)**Major**: **+.0**|(% style="width:1034px" %)After the change, the parent code for the changed hierarchy does not represent the same aggregation any more, thus resulting in a break in backward compatibility
78		-|(% style="width:877px" %)**Aggregation, disaggregation, reorganisation or removal of one or more codes**|(% style="width:161px" %)**Major**: **+.0**|(% style="width:1034px" %)Data exchanged/disseminated using an old version of the CL can no longer be exchanged/disseminated using the new version of the CL
	75	+)))|**Minor**: **N.,,+,,^^(^^**^^3)^^|Data exchanged/disseminated using the old CL can still be exchanged/disseminated using the new CL as already existing hierarchies still represent the same aggregations
	76	+|**Addition of one or more new codes into existing hierarchies represented using the CodeList:Code:ParentCode attribute (not using the Hierarchical Code List artefact)**|**Major**: **+.0**|After the change, the parent code for the changed hierarchy does not represent the same aggregation any more, thus resulting in a break in backward compatibility
	77	+|**Aggregation, disaggregation, reorganisation or removal of one or more codes**|**Major**: **+.0**|Data exchanged/disseminated using an old version of the CL can no longer be exchanged/disseminated using the new version of the CL
79	79
80	80
81	81
82	82	|(% colspan="3" %)**HIERARCHICAL CODE LIST (HCL)**
83		-|**Type of Change**|(% style="width:150px" %)**Impact**|(% style="width:1045px" %)**Comments**
	82	+|**Type of Change**|**Impact**|**Comments**
84	84	|(((
85		-**Addition of new hierarchies in the HCL. Existing hierarchies are unaffected**
86		-)))|(% style="width:150px" %)**Minor**: **N.,,+,,**^^({{footnote}}The overall impact on compatibility should be assessed when there are several “minor” version impact changes. For example, it may be that the effect of adding several new Code List or HCL codes results in an implicit change in the meaning of existing Code List or HCL codes which may not be completely backward compatible, therefore (depending on the analysis) the overall version impact may be “Major +.0”.{{/footnote}})^^|(% style="width:1045px" %)Data represented using the old HCL can still be represented using the new HCL
87		-|**Addition of codes into existing hierarchies in the HCL. Existing hierarchies are thus affected**|(% style="width:150px" %)**Major**: **+.0**|(% style="width:1045px" %)The HCL resulting from this change does not represent the same aggregation any more, thus breaking backward compatibility
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		-|**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
	84	+**Addition of new hierarchies in the HCL.**
90	90
	86	+**Existing hierarchies are unaffected**
	87	+)))|**Minor**: **N.,,+,,**^^(3)^^|Data represented using the old HCL can still be represented using the new HCL
	88	+|**Addition of codes into existing hierarchies in the HCL. Existing hierarchies are thus affected**|**Major**: **+.0**|The HCL resulting from this change does not represent the same aggregation any more, thus breaking backward compatibility
	89	+|**Removal of one or more codes in the HCL or removal of one or more codes in the referenced code lists**|**Major**: **+.0**|Data represented using the old HCL can no longer be represented using the new HCL, thus resulting in a break in backward compatibility
	90	+|**Addition, modification or removal of one or more hierarchical levels**|**Major: +.0**|The reorganisation of codes within hierarchies has a significant impact on the code aggregations
	91	+
	92	+
	93	+
91	91	|(% colspan="3" %)**CONCEPT SCHEME (CS)**
92		-|(% style="width:874px" %)**Type of change**|(% style="width:154px" %)**Impact**|(% style="width:1044px" %)**Comments**
93		-|(% style="width:874px" %)**Addition of one or more new concepts in an existing CS**|(% style="width:154px" %)**Minor**: **N.+**|(% style="width:1044px" %)(((
94		-Data exchanged/disseminated using the old version of the CS can still be exchanged/disseminated using the new CS
	95	+|**Type of change**|**Impact**|**Comments**
	96	+|**Addition of one or more new concepts in an existing CS**|**Minor**: **N.+**|(((
	97	+Data exchanged/disseminated using the old version of the
	98	+
	99	+CS can still be exchanged/disseminated using the new CS
95	95	)))
96		-|(% 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
	101	+|**Removal of one or more existing concepts**|**Major: +.0**|Data exchanged/disseminated using the old version of the CS can no longer be exchanged/disseminated using the new version with less concepts
97	97
	103	+
	104	+
98	98	|(% colspan="3" %)**DATA STRUCTURE DEFINITION (DSD)**
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
	106	+|**Type of change**|**Impact**|**Comments**
	107	+|**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
	108	+|**Addition of a mandatory attribute**|**Major**: **+.0**|If the attribute is mandatory, the situation is the same as under point “Addition of a dimension”
	109	+|**Addition of a conditional attribute**|**Minor**: **N.+**|If the attribute is conditional backward compatibility is maintained
	110	+|**Removal of a dimension or attribute**|**Major**: **+.0**|Whatever the type of component, the change does not guarantee backward compatibility
104	104
105	105	For concrete examples, see the Appendix.
106	106
107		-= 5. How versioning works for inter-dependent artefacts =
	114	+=== 5. How versioning works for inter-dependent artefacts ===
108	108
109	109	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.
110	110