Changes for page Guidelines on coding time transformations in SDMX

Summary

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

Details

Page properties

Content

...	...	@@ -81,7 +81,8 @@
81	81	|**2**|Two|
82	82	|**etc.**|etc.|
83	83
84		-== 2.3 Relation of transformation coding to transformation rules ==
	84	+1.
	85	+11. Relation of transformation coding to transformation rules
85	85
86	86	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:
87	87
...	...	@@ -100,6 +100,8 @@
100	100	(VTL)
101	101	)))
102	102
	104	+
	105	+
103	103	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.
104	104
105	105	**Example:**
...	...	@@ -143,7 +143,8 @@
143	143
144	144	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.
145	145
146		-== 2.4 Recommendation ==
	149	+1.
	150	+11. Recommendation
147	147
148	148	Where possible, it is recommended to use the above solution with the two concepts TIMETRANS_TYPE and TIMETRANS_PER to express time transformations because:
149	149
...	...	@@ -151,10 +151,9 @@
151	151	* it is possible to add extra concepts if required without introducing ambiguity;
152	152	* the coded transformations can be linked directly with transformation formulas.
153	153
154		-= 3. Compound coding for time transformations =
	158	+1. Compound coding for time transformations
	159	+11. Known Limitations
155	155
156		-== 3.1 Known Limitations ==
157		-
158	158	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).
159	159
160	160	A "transformation frequency" might be added to keep the normalised approach also for those cases.
...	...	@@ -167,6 +167,8 @@
167	167
168	168	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]].
169	169
	173	+
	174	+
170	170	Example for composite CL_TIMETRANS:
171	171
172	172	|**Recommended code value**|**Recommended