Skip to Content
Last modified by Artur on 2025/09/10 11:19
From version 1.10
edited by Helena
on 2025/06/16 13:03
Change comment: There is no comment for this version
To version 1.11
edited by Helena
on 2025/06/16 13:08
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -2,8 +2,7 @@
2 2  {{toc/}}
3 3  {{/box}}
4 4  
5 -1.
6 -11. Introduction
5 +== 12.1 Introduction ==
7 7  
8 8  The Validation and Transformation Language (VTL) supports the definition of Transformations, which are algorithms to calculate new data starting from already existing ones{{footnote}}The Validation and Transformation Language is a standard language designed and published under the SDMX initiative. VTL is described in the VTL User and Reference Guides available on the SDMX website https://sdmx.org.{{/footnote}}. The purpose of the VTL in the SDMX context is to enable the:
9 9  
... ... @@ -19,9 +19,8 @@
19 19  
20 20  This section does not explain the VTL language or any of the content published in the VTL guides. Rather, this is a description of how the VTL can be used in the SDMX context and applied to SDMX artefacts.
21 21  
22 -1.
23 -11. References to SDMX artefacts from VTL statements
24 -111. Introduction
21 +== 12.2 References to SDMX artefacts from VTL statements ==
22 +=== 12.2.1 Introduction ===
25 25  
26 26  The VTL can manipulate SDMX artefacts (or objects) by referencing them through predefined conventional names (aliases).
27 27  
... ... @@ -33,9 +33,7 @@
33 33  
34 34  The references through the URN and the abbreviated URN are described in the following paragraphs.
35 35  
36 -1.
37 -11.
38 -111. References through the URN
34 +=== 12.2.2 References through the URN ===
39 39  
40 40  This approach has the advantage that in the VTL code the URN of the referenced artefacts is directly intelligible by a human reader but has the drawback that the references are verbose.
41 41  
... ... @@ -94,9 +94,7 @@
94 94  
95 95  'urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=AG:DF2(1.0.0)'
96 96  
97 -1.
98 -11.
99 -111. Abbreviation of the URN
93 +=== 12.2.3 Abbreviation of the URN ===
100 100  
101 101  The complete formulation of the URN described above is exhaustive but verbose, even for very simple statements. In order to reduce the verbosity through a simplified identifier and make the work of transformation definers easier, proper abbreviations of the URN are possible. Using this approach, the referenced artefacts remain intelligible in the VTL code by a human reader.
102 102  
... ... @@ -108,11 +108,7 @@
108 108  * The class-name can be omitted as it can be deduced from the VTL invocation. In particular, starting from the VTL class of the invoked artefact (e.g. dataset, component, identifier, measure, attribute, variable, valuedomain), which is known given the syntax of the invoking VTL operator{{footnote}}For the syntax of the VTL operators see the VTL Reference Manual{{/footnote}}, the SDMX class can be deduced from the mapping rules between VTL and SDMX (see the section "Mapping between VTL and SDMX" hereinafter){{footnote}}In case the invoked artefact is a VTL component, which can be invoked only within the invocation of a VTL data set (SDMX Dataflow), the specific SDMX class-name (e.g. Dimension, TimeDimension, Measure or DataAttribute) can be deduced from the data structure of the SDMX Dataflow, which the component belongs to.{{/footnote}}.
109 109  * If the agency-id is not specified, it is assumed by default equal to the agency-id of the TransformationScheme, UserDefinedOperatorScheme or RulesetScheme from which the artefact is invoked. For example, the agencyid can be omitted if it is the same as the invoking TransformationScheme and cannot be omitted if the artefact comes from another agency{{footnote}}If the Agency is composite (for example AgencyA.Dept1.Unit2), the agency is considered different even if only part of the composite name is different (for example AgencyA.Dept1.Unit3 is a different Agency than the previous one). Moreover the agency-id cannot be omitted in part (i.e., if a TransformationScheme owned by AgencyA.Dept1.Unit2 references an artefact coming from AgencyA.Dept1.Unit3, the specification of the agency-id becomes mandatory and must be complete, without omitting the possibly equal parts like AgencyA.Dept1){{/footnote}}. Take also into account that, according to the VTL consistency rules, the agency of the result of a Transformation must be the same as its TransformationScheme, therefore the agency-id can be omitted for all the results (left part of Transformation statements).
110 110  * As for the maintainedobject-id, this is essential in some cases while in other cases it can be omitted: o if the referenced artefact is a Dataflow, which is a maintainable class, the maintainedobject-id is the dataflow-id and obviously cannot be omitted;
111 -** if the referenced artefact is a Dimension, TimeDimension, Measure,
112 -
113 -DataAttribute, which are not maintainable and belong to the DataStructure maintainable class, the maintainedobject-id is the dataStructure-id and can be omitted, given that these components are always invoked within the invocation of a Dataflow, whose dataStructure-id can be deduced from the SDMX structural definitions;
114 -
115 -*
105 +** if the referenced artefact is a Dimension, TimeDimension, Measure, DataAttribute, which are not maintainable and belong to the DataStructure maintainable class, the maintainedobject-id is the dataStructure-id and can be omitted, given that these components are always invoked within the invocation of a Dataflow, whose dataStructure-id can be deduced from the SDMX structural definitions;
116 116  ** if the referenced artefact is a Concept, which is not maintainable and belong to the ConceptScheme maintainable class, the maintained object is the conceptScheme-id and cannot be omitted;
117 117  ** if the referenced artefact is a Codelist, which is a maintainable class, the maintainedobject-id is the codelist-id and obviously cannot be omitted.
118 118  * When the maintainedobject-id is omitted, the maintainedobject-version is omitted too. When the maintainedobject-id is not omitted and the maintainedobject-version is omitted, the version 1.0 is assumed by default.
... ... @@ -171,17 +171,13 @@
171 171  
172 172  The artefact (Component, Concept, Codelist …) which the Values are referred to can be deduced from the context in which the reference is made, taking also into account the VTL syntax. In the Transformation above, for example, the values 0 and 2500 are compared to the values of the measures of DF1(1.0.0).
173 173  
174 -1.
175 -11.
176 -111. User-defined alias
164 +=== 12.2.4 User-defined alias ===
177 177  
178 178  The third possibility for referencing SDMX artefacts from VTL statements is to use user-defined aliases not related to the SDMX URN of the artefact.
179 179  
180 180  This approach gives preference to the use of symbolic names for the SDMX artefacts. As a consequence, in the VTL code the referenced artefacts may become not directly intelligible by a human reader. In any case, the VTL aliases are associated to the SDMX URN through the VtlMappingScheme and VtlMapping classes. These classes provide for structured references to SDMX artefacts whatever kind of reference is used in VTL statements (URN, abbreviated URN or user-defined aliases).
181 181  
182 -1.
183 -11.
184 -111. References to SDMX artefacts from VTL Rulesets
170 +=== 12.2.5 References to SDMX artefacts from VTL Rulesets ===
185 185  
186 186  The VTL Rulesets allow defining sets of reusable Rules that can be applied by some VTL operators, like the ones for validation and hierarchical roll-up. A "Rule" consists in a relationship between Values belonging to some Value Domains or taken by some Variables, for example: (i) when the Country is USA then the Currency is USD; (ii) the Benelux is composed by Belgium, Luxembourg, Netherlands.
187 187  
... ... @@ -193,9 +193,8 @@
193 193  
194 194  In the body of the Rulesets, the Codes and in general all the Values can be written without any other specification, because the artefact, which the Values are referred (Codelist, Concept) to can be deduced from the Ruleset signature.
195 195  
196 -1.
197 -11. Mapping between SDMX and VTL artefacts
198 -111. When the mapping occurs
182 +== 12.3 Mapping between SDMX and VTL artefacts ==
183 +=== 12.3.1. When the mapping occurs ===
199 199  
200 200  The mapping methods between the VTL and SDMX object classes allow transforming a SDMX definition in a VTL one and vice-versa for the artefacts to be manipulated. It should be remembered that VTL programs (i.e. Transformation Schemes) are represented in SDMX through the TransformationScheme maintainable class which is composed of Transformations (nameable artefacts). Each Transformation assigns the outcome of the evaluation of a VTL expression to a result: the input operands of the expression and the result can be SDMX artefacts. Every time a SDMX object is referenced in a VTL Transformation as an input operand, there is the need to generate a VTL definition of the object, so that the VTL operations can take place. This can be made starting from the SDMX definition and applying a SDMX-VTL mapping method in the direction from SDMX to VTL. The possible mapping methods from SDMX to VTL are described in the following paragraphs and are conceived to allow the automatic deduction of the VTL definition of the object from the knowledge of the SDMX definition.
201 201  
... ... @@ -203,9 +203,7 @@
203 203  
204 204  The mapping methods from VTL to SDMX are described in the following paragraphs as well, however they do not allow the complete SDMX definition to be automatically deduced from the VTL definition, more than all because the former typically contains additional information in respect to the latter. For example, the definition of a SDMX DSD includes also some mandatory information not available in VTL (like the concept scheme to which the SDMX components refer, the ‘usage’ and ‘attributeRelationship’ for the DataAttributes and so on). Therefore the mapping methods from VTL to SDMX provide only a general guidance for generating SDMX definitions properly starting from the information available in VTL, independently of how the SDMX definition it is actually generated (manually, automatically or part and part).
205 205  
206 -1.
207 -11.
208 -111. General mapping of VTL and SDMX data structures
191 +=== 12.3.2 General mapping of VTL and SDMX data structures ===
209 209  
210 210  This section makes reference to the VTL "Model for data and their structure"{{footnote}}See the VTL 2.0 User Manual{{/footnote}} and the correspondent SDMX "Data Structure Definition"{{footnote}}See the SDMX Standards Section 2 – Information Model{{/footnote}}.
211 211  
... ... @@ -221,11 +221,9 @@
221 221  
222 222  The possible mapping options are described in more detail in the following sections.
223 223  
224 -1.
225 -11.
226 -111. Mapping from SDMX to VTL data structures
207 +=== 12.3.2 Mapping from SDMX to VTL data structures ===
227 227  
228 -**12.3.3.1 Basic Mapping**
209 +==== 12.3.3.1 Basic Mapping ====
229 229  
230 230  The main mapping method from SDMX to VTL is called **Basic **mapping. This is considered as the default mapping method and is applied unless a different method is specified through the VtlMappingScheme and VtlDataflowMapping classes.
231 231