Changes for page Guidelines on coding time transformations in SDMX

Summary

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

Details

Page properties

Content

...	...	@@ -81,8 +81,7 @@
81	81	|**2**|Two|
82	82	|**etc.**|etc.|
83	83
84		-1.
85		-11. Relation of transformation coding to transformation rules
	84	+== 2.3 Relation of transformation coding to transformation rules ==
86	86
87	87	Transformation can also be expressed with transformation rules using a syntax such as the Validation and Transformation Language (VTL). Following the transformation graph model behind VTL, the transformation coding suggested in this guideline can be seen complementary with using transformation rules in VTL. The idea is that a coded non-transformed time series is transformed using a VTL rule and the result is then coded again with transformation codes for further data exchange. This principle is shown in the graph below:
88	88
...	...	@@ -101,8 +101,6 @@
101	101	(VTL)
102	102	)))
103	103
104		-
105		-
106	106	Using the two concepts as suggested above for coding the type of transformation applied and the number of periods covered will additionally ensure that the parameters used for the formula are directly used in the coding of the resulting series. Thus no complex mapping is needed. The transformation applied is linked to the transformation type concept and the number of periods used for the calculation is linked to the transformation periods concept.
107	107
108	108	**Example:**
...	...	@@ -146,8 +146,7 @@
146	146
147	147	This is especially useful when only transformed series should be exchanged and level series or transformations are not subject to exchange. An example could be GDP growth rates, where for early estimates often level series are still under embargo, whereas growth rates are publishable.
148	148
149		-1.
150		-11. Recommendation
	146	+== 2.4 Recommendation ==
151	151
152	152	Where possible, it is recommended to use the above solution with the two concepts TIMETRANS_TYPE and TIMETRANS_PER to express time transformations because:
153	153
...	...	@@ -155,9 +155,10 @@
155	155	* it is possible to add extra concepts if required without introducing ambiguity;
156	156	* the coded transformations can be linked directly with transformation formulas.
157	157
158		-1. Compound coding for time transformations
159		-11. Known Limitations
	154	+= 3. Compound coding for time transformations =
160	160
	156	+== 3.1 Known Limitations ==
	157	+
161	161	The normalised approach as presented above does not support the definition of mixed-frequency time transformations – like monthly series of annual growth rates – since there is only a single frequency dimension available. This also means that when annual growth rates are expressed in a quarterly dataset, the time transformation period would need to be modified (i.e. when frequency changes from A to Q, the number of periods need to be quadrupled).
162	162
163	163	A "transformation frequency" might be added to keep the normalised approach also for those cases.
...	...	@@ -170,8 +170,6 @@
170	170
171	171	The number of periods in the code follows the frequency of the series unless stated otherwise. Example: code G3Y refers to a three-year growth rate, irrespective of the series frequency. For complex transformations, the codes that would be used for the respective transformations can be concatenated and separated by an underscore[[~[4~]>>path:#_ftn4]].
172	172
173		-
174		-
175	175	Example for composite CL_TIMETRANS:
176	176
177	177	|**Recommended code value**|**Recommended