Changes for page 12 Validation and Transformation Language (VTL)
Last modified by Artur on 2025/09/10 11:19
Summary
-
Page properties (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -5,7 +5,7 @@ 5 5 1. 6 6 11. Introduction 7 7 8 -The Validation and Transformation Language (VTL) supports the definition of Transformations, which are algorithms to calculate new data starting from already existing ones [[(% class="wikiinternallink wikiinternallink wikiinternallinkwikiinternallink wikiinternallink wikiinternallinkwikiinternallinkwikiinternallink wikiinternallink wikiinternallinkwikiinternallinkwikiinternallinkwikiinternallink wikiinternallinkwikiinternallink wikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallink wikiinternallinkwikiinternallinkwikiinternallink wikiinternallink"%)^^~[1~]^^>>path:#_ftn1]](%%). The purpose of the VTL in the SDMX context is to enable the: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 10 10 * definition of validation and transformation algorithms, in order to specify how to calculate new data from existing ones; 11 11 * exchange of the definition of VTL algorithms, also together the definition of the data structures of the involved data (for example, exchange the data structures of a reporting framework together with the validation rules to be applied, exchange the input and output data structures of a calculation task together with the VTL Transformations describing the calculation algorithms); ... ... @@ -13,7 +13,7 @@ 13 13 14 14 It is important to note that the VTL has its own information model (IM), derived from the Generic Statistical Information Model (GSIM) and described in the VTL User Guide. The VTL IM is designed to be compatible with more standards, like SDMX, DDI (Data Documentation Initiative) and GSIM, and includes the model artefacts that can be manipulated (inputs and/or outputs of Transformations, e.g. "Data Set", "Data Structure") and the model artefacts that allow the definition of the transformation algorithms (e.g. "Transformation", "Transformation Scheme"). 15 15 16 -The VTL language can be applied to SDMX artefacts by mapping the SDMX IM model artefacts to the model artefacts that VTL can manipulate [[(% class="wikiinternallink wikiinternallinkwikiinternallinkwikiinternallink wikiinternallinkwikiinternallinkwikiinternallink wikiinternallinkwikiinternallinkwikiinternallink wikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallink wikiinternallink wikiinternallinkwikiinternallinkwikiinternallinkwikiinternallink wikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallink wikiinternallink"%)^^~[2~]^^>>path:#_ftn2]](%%). Thus, the SDMX artefacts can be used in VTL as inputs and/or outputs of Transformations. It is important to be aware that the artefacts do not always have the same names in the SDMX and VTL IMs, nor do they always have the same meaning. The more evident example is given by the SDMX Dataset and the VTL "Data Set", which do not correspond one another: as a matter of fact, the VTL "Data Set" maps to the SDMX "Dataflow", while the SDMX "Dataset" has no explicit mapping to VTL (such an abstraction is not needed in the definition of VTL Transformations). A SDMX "Dataset", however, is an instance of a SDMX "Dataflow" and can be the artefact on which the VTL transformations are executed (i.e., the Transformations are defined on Dataflows and are applied to Dataflow instances that can be Datasets).16 +The VTL language can be applied to SDMX artefacts by mapping the SDMX IM model artefacts to the model artefacts that VTL can manipulate{{footnote}}In this chapter, in order to distinguish VTL and SDMX model artefacts, the VTL ones are written in the Arial font while the SDMX ones in Courier New.{{/footnote}}. Thus, the SDMX artefacts can be used in VTL as inputs and/or outputs of Transformations. It is important to be aware that the artefacts do not always have the same names in the SDMX and VTL IMs, nor do they always have the same meaning. The more evident example is given by the SDMX Dataset and the VTL "Data Set", which do not correspond one another: as a matter of fact, the VTL "Data Set" maps to the SDMX "Dataflow", while the SDMX "Dataset" has no explicit mapping to VTL (such an abstraction is not needed in the definition of VTL Transformations). A SDMX "Dataset", however, is an instance of a SDMX "Dataflow" and can be the artefact on which the VTL transformations are executed (i.e., the Transformations are defined on Dataflows and are applied to Dataflow instances that can be Datasets). 17 17 18 18 The VTL programs (Transformation Schemes) are represented in SDMX through the TransformationScheme maintainable class which is composed of Transformation (nameable artefact). Each Transformation assigns the outcome of the evaluation of a VTL expression to a result. 19 19 ... ... @@ -27,7 +27,7 @@ 27 27 28 28 The alias of an SDMX artefact can be its URN (Universal Resource Name), an abbreviation of its URN or another user-defined name. 29 29 30 -In any case, the aliases used in the VTL Transformations have to be mapped to the SDMX artefacts through the VtlMappingScheme and VtlMapping classes (see the section of the SDMX IM relevant to the VTL). A VtlMapping allows specifying the aliases to be used in the VTL Transformations, Rulesets [[(% class="wikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallink wikiinternallink wikiinternallinkwikiinternallinkwikiinternallinkwikiinternallink wikiinternallink wikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallink wikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallink"%)^^~[3~]^^>>path:#_ftn3]](%%)orUserDefinedOperators[[(%class="wikiinternallinkwikiinternallink wikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallink wikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallink wikiinternallinkwikiinternallink wikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallink wikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallink" %)^^~[4~]^^>>path:#_ftn4]](%%)to reference SDMX artefacts. A VtlMappingScheme is a container for zero or more VtlMapping.30 +In any case, the aliases used in the VTL Transformations have to be mapped to the SDMX artefacts through the VtlMappingScheme and VtlMapping classes (see the section of the SDMX IM relevant to the VTL). A VtlMapping allows specifying the aliases to be used in the VTL Transformations, Rulesets{{footnote}}See also the section "VTL-DL Rulesets" in the VTL Reference Manual.{{/footnote}} or User Defined Operators{{footnote}}The VTLMappings are used also for User Defined Operators (UDO). Although UDOs are envisaged to be defined on generic operands, so that the specific artefacts to be manipulated are passed as parameters at their invocation, it is also possible that an UDO invokes directly some specific SDMX artefacts. These SDMX artefacts have to be mapped to the corresponding aliases used in the definition of the UDO through the VtlMappingScheme and VtlMapping classes as well.{{/footnote}} to reference SDMX artefacts. A VtlMappingScheme is a container for zero or more VtlMapping. 31 31 32 32 The correspondence between an alias and a SDMX artefact must be one-to-one, meaning that a generic alias identifies one and just one SDMX artefact while a SDMX artefact is identified by one and just one alias. In other words, within a VtlMappingScheme an artefact can have just one alias and different artefacts cannot have the same alias. 33 33 ... ... @@ -39,7 +39,7 @@ 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 42 -The SDMX URN [[(% class="wikiinternallink wikiinternallinkwikiinternallinkwikiinternallink wikiinternallink wikiinternallinkwikiinternallink wikiinternallinkwikiinternallinkwikiinternallinkwikiinternallink wikiinternallink wikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallink wikiinternallinkwikiinternallink wikiinternallinkwikiinternallink wikiinternallinkwikiinternallinkwikiinternallinkwikiinternallink wikiinternallinkwikiinternallink" %)^^~[5~]^^>>path:#_ftn5]](%%)is the concatenation of the following parts, separated by special symbols like dot, equal, asterisk, comma, and parenthesis:42 +The SDMX URN{{footnote}}For a complete description of the structure of the URN see the SDMX 2.1 Standards - Section 5 - Registry Specifications, paragraph 6.2.2 ("Universal Resource Name (URN)").{{/footnote}}(% style="font-size:12px" %) (%%)is the concatenation of the following parts, separated by special symbols like dot, equal, asterisk, comma, and parenthesis: 43 43 44 44 * SDMXprefix 45 45 * SDMX-IM-package-name ... ... @@ -47,7 +47,7 @@ 47 47 * agency-id 48 48 * maintainedobject-id 49 49 * maintainedobject-version 50 -* container-object-id [[(% class="wikiinternallink wikiinternallink wikiinternallinkwikiinternallink wikiinternallink wikiinternallink wikiinternallinkwikiinternallinkwikiinternallink wikiinternallink wikiinternallink wikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[6~]^^>>path:#_ftn6]]50 +* container-object-id{{footnote}}The container-object-id can repeat and may not be present.{{/footnote}} 51 51 * object-id 52 52 53 53 The generic structure of the URN is the following: ... ... @@ -64,7 +64,7 @@ 64 64 65 65 The agency-id is the acronym of the agency that owns the definition of the artefact, for example for the Eurostat artefacts the agency-id is "ESTAT"). The agency-id can be composite (for example AgencyA.Dept1.Unit2). 66 66 67 -The maintainedobject-id is the name of the maintained object which the artefact belongs to, and in case the artefact itself is maintainable [[(% class="wikiinternallink wikiinternallink wikiinternallinkwikiinternallinkwikiinternallink wikiinternallink wikiinternallink wikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallink wikiinternallink wikiinternallink wikiinternallinkwikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[7~]^^>>path:#_ftn7]](%%), coincides with the name of the artefact. Therefore the maintainedobject-id depends on the class of the artefact:67 +The maintainedobject-id is the name of the maintained object which the artefact belongs to, and in case the artefact itself is maintainable{{footnote}}i.e., the artefact belongs to a maintainable class{{/footnote}}, coincides with the name of the artefact. Therefore the maintainedobject-id depends on the class of the artefact: 68 68 69 69 * if the artefact is a Dataflow, which is a maintainable class, the maintainedobject-id is the Dataflow name (dataflow-id); 70 70 * if the artefact is a Dimension, Measure, TimeDimension or DataAttribute, which are not maintainable and belong to the ... ... @@ -86,7 +86,7 @@ 86 86 87 87 * if the artefact is a Concept (the object-id is the name of the Concept) 88 88 89 -For example, by using the URN, the VTL Transformation that sums two SDMX Dataflows DF1 and DF2 and assigns the result to a third persistent Dataflow DFR, assuming that DF1, DF2 and DFR are the maintainedobject-id of the three Dataflows, that their version is 1.0.0 and their Agency is AG, would be written as [[(% class="wikiinternallink wikiinternallink wikiinternallinkwikiinternallink wikiinternallinkwikiinternallink wikiinternallink wikiinternallink wikiinternallinkwikiinternallinkwikiinternallinkwikiinternallink wikiinternallink wikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallink wikiinternallinkwikiinternallinkwikiinternallink" %)^^~[8~]^^>>path:#_ftn8]](%%):89 +For example, by using the URN, the VTL Transformation that sums two SDMX Dataflows DF1 and DF2 and assigns the result to a third persistent Dataflow DFR, assuming that DF1, DF2 and DFR are the maintainedobject-id of the three Dataflows, that their version is 1.0.0 and their Agency is AG, would be written as{{footnote}}Since these references to SDMX objects include non-permitted characters as per the VTL ID notation, they need to be included between single quotes, according to the VTL rules for irregular names.{{/footnote}}: 90 90 91 91 'urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=AG:DFR(1.0.0)' <- 92 92 ... ... @@ -105,7 +105,7 @@ 105 105 * The SDMXprefix can be omitted for all the SDMX objects, because it is a prefixed string (urn:sdmx:org), always the same for SDMX objects. 106 106 * The SDMX-IM-package-name** **can be omitted as well because it can be deduced from the class-name that follows it (the table of the SDMX-IM packages and classes that allows this deduction is in the SDMX 2.1 Standards - Section 5 - Registry Specifications, paragraph 6.2.3). In particular, considering the object classes of the artefacts that VTL can reference, the package is: 107 107 ** "datastructure" for the classes Dataflow, Dimension, TimeDimension, Measure, DataAttribute, o "conceptscheme" for the class Concept, o "codelist" for the class Codelist. 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 [[(% class="wikiinternallink wikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallinkwikiinternallink wikiinternallinkwikiinternallink wikiinternallinkwikiinternallinkwikiinternallinkwikiinternallink wikiinternallink wikiinternallink wikiinternallinkwikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[9~]^^>>path:#_ftn9]](%%), 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}}.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 111 ** if the referenced artefact is a Dimension, TimeDimension, Measure, ... ... @@ -947,23 +947,4 @@ 947 947 948 948 ---- 949 949 950 -[[~[1~]>>path:#_ftnref1]] 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>>url:https://sdmx.org/]][[.>>url:https://sdmx.org/]] 951 - 952 -[[~[2~]>>path:#_ftnref2]] In this chapter, in order to distinguish VTL and SDMX model artefacts, the VTL ones are written in the Arial font while the SDMX ones in Courier New 953 - 954 -[[~[3~]>>path:#_ftnref3]] See also the section "VTL-DL Rulesets" in the VTL Reference Manual. 955 - 956 -[[~[4~]>>path:#_ftnref4]] The VTLMappings are used also for User Defined Operators (UDO). Although UDOs are envisaged to be defined on generic operands, so that the specific artefacts to be manipulated are passed as parameters at their invocation, it is also possible that an UDO invokes directly some specific SDMX artefacts. These SDMX artefacts have to be mapped to the corresponding aliases used in the definition of the UDO through the VtlMappingScheme and VtlMapping classes as well. 957 - 958 -[[~[5~]>>path:#_ftnref5]] For a complete description of the structure of the URN see the SDMX 2.1 Standards - Section 5 - Registry Specifications, paragraph 6.2.2 ("Universal Resource Name (URN)"). 959 - 960 -[[~[6~]>>path:#_ftnref6]] The container-object-id can repeat and may not be present. 961 - 962 -[[~[7~]>>path:#_ftnref7]] i.e., the artefact belongs to a maintainable class 963 - 964 -[[~[8~]>>path:#_ftnref8]] Since these references to SDMX objects include non-permitted characters as per the VTL ID notation, they need to be included between single quotes, according to the VTL rules for irregular names. 965 - 966 -[[~[9~]>>path:#_ftnref9]] For the syntax of the VTL operators see the VTL Reference Manual 967 - 968 - 969 969 {{putFootnotes/}}