Changes for page 12 Validation and Transformation Language (VTL)

Last modified by Helena on 2025/09/10 11:19

From 5.9 to 5.8 From 5.16 to 5.15

From version 5.15

edited by Helena
on 2025/05/16 08:45

Change comment: There is no comment for this version

To version 5.9

edited by Helena
on 2025/05/16 08:32

Change comment: There is no comment for this version

Raw
Rendered

Summary

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

Details

Page properties

Content

@@ -114,11 +114,11 @@
  DFR := DF1 + DF2
--The references to the Codelists can be simplified similarly. For example, given the non-abbreviated reference to the Codelist AG:CL_FREQ(1.0.0), which is{{footnote}}Single quotes are needed because this reference is not a VTL regular name.{{/footnote}}:
++The references to the Codelists can be simplified similarly. For example, given the non-abbreviated reference to the Codelist AG:CL_FREQ(1.0.0), which is^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^16^^>>path:#sdfootnote16sym||name="sdfootnote16anc"]](%%)^^:
  'urn:sdmx:org.sdmx.infomodel.codelist.Codelist=AG:CL_FREQ(1.0.0)'
--if the Codelist is referenced from a RulesetScheme belonging to the agency AG, omitting all the optional parts, the abbreviated reference would become simply{{footnote}}Single quotes are not needed in this case because CL_FREQ is a VTL regular name.{{/footnote}}:
++if the Codelist is referenced from a RulesetScheme belonging to the agency AG, omitting all the optional parts, the abbreviated reference would become simply^^19^^:
  CL_FREQ
@@ -132,7 +132,7 @@
  SECTOR
--For example, the Transformation for renaming the component SECTOR of the Dataflow DF1 into SEC can be written as{{footnote}}The result DFR(1.0.0) is be equal to DF1(1.0.0) save that the component SECTOR is called SEC{{/footnote}}:
++For example, the Transformation for renaming the component SECTOR of the Dataflow DF1 into SEC can be written as^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^17^^>>path:#sdfootnote17sym||name="sdfootnote17anc"]](%%)^^:
  'DFR(1.0.0)' := 'DF1(1.0.0)' [rename SECTOR to SEC]
@@ -164,9 +164,9 @@
  The VTL Rulesets have a signature, in which the Value Domains or the Variables on which the Ruleset is defined are declared, and a body, which contains the Rules.
--In the signature, given the mapping between VTL and SDMX better described in the following paragraphs, a reference to a VTL Value Domain becomes a reference to a SDMX Codelist, while a reference to a VTL Represented Variable becomes a reference to a SDMX Concept, assuming for it a definite representation{{footnote}}Rulesets of this kind cannot be reused when the referenced Concept has a different representation.{{/footnote}}.
++In the signature, given the mapping between VTL and SDMX better described in the following paragraphs, a reference to a VTL Value Domain becomes a reference to a SDMX Codelist, while a reference to a VTL Represented Variable becomes a reference to a SDMX Concept, assuming for it a definite representation^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^18^^>>path:#sdfootnote18sym||name="sdfootnote18anc"]](%%)^^.
--In general, for referencing SDMX Codelists and Concepts, the conventions described in the previous paragraphs apply. In the Ruleset syntax, the elements that reference SDMX artefacts are called "valueDomain" and "variable" for the Datapoint Rulesets and "ruleValueDomain", "ruleVariable", "condValueDomain" "condVariable" for the Hierarchical Rulesets). The syntax of the Ruleset signature allows also to define aliases of the elements above, these aliases are valid only within the specific Ruleset definition statement and cannot be mapped to SDMX.{{footnote}}See also the section "VTL-DL Rulesets" in the VTL Reference Manual.{{/footnote}}
++In general, for referencing SDMX Codelists and Concepts, the conventions described in the previous paragraphs apply. In the Ruleset syntax, the elements that reference SDMX artefacts are called "valueDomain" and "variable" for the Datapoint Rulesets and "ruleValueDomain", "ruleVariable", "condValueDomain" "condVariable" for the Hierarchical Rulesets). The syntax of the Ruleset signature allows also to define aliases of the elements above, these aliases are valid only within the specific Ruleset definition statement and cannot be mapped to SDMX.^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^19^^>>path:#sdfootnote19sym||name="sdfootnote19anc"]](%%)^^
  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.
@@ -178,15 +178,15 @@
  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.
--In the opposite direction, every time an object calculated by means of VTL must be treated as a SDMX object (for example for exchanging it through SDMX), there is the need of a SDMX definition of the object, so that the SDMX operations can take place. The SDMX definition is needed for the VTL objects for which a SDMX use is envisaged{{footnote}}If a calculated artefact is persistent, it needs a persistent definition, i.e. a SDMX definition in a SDMX environment. In addition, possible calculated artefact that are not persistent may require a SDMX definition, for example when the result of a non-persistent calculation is disseminated through SDMX tools (like an inquiry tool).{{/footnote}}.
++In the opposite direction, every time an object calculated by means of VTL must be treated as a SDMX object (for example for exchanging it through SDMX), there is the need of a SDMX definition of the object, so that the SDMX operations can take place. The SDMX definition is needed for the VTL objects for which a SDMX use is envisaged^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^20^^>>path:#sdfootnote20sym||name="sdfootnote20anc"]](%%)^^.
  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).
  === 12.3.2 General mapping of VTL and SDMX data structures ===
--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}}.
++This section makes reference to the VTL "Model for data and their structure"^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^21^^>>path:#sdfootnote21sym||name="sdfootnote21anc"]](%%)^^ and the correspondent SDMX "Data Structure Definition"^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^22^^>>path:#sdfootnote22sym||name="sdfootnote22anc"]](%%)^^.
--The main type of artefact that the VTL can manipulate is the VTL Data Set, which in general is mapped to the SDMX Dataflow. This means that a VTL Transformation, in the SDMX context, expresses the algorithm for calculating a derived Dataflow starting from some already existing Dataflows (either collected or derived).{{footnote}}Besides the mapping between one SDMX Dataflow and one VTL Data Set, it is also possible to map distinct parts of a SDMX Dataflow to different VTL Data Set, as explained in a following paragraph.{{/footnote}}
++The main type of artefact that the VTL can manipulate is the VTL Data Set, which in general is mapped to the SDMX Dataflow. This means that a VTL Transformation, in the SDMX context, expresses the algorithm for calculating a derived Dataflow starting from some already existing Dataflows (either collected or derived).^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^23^^>>path:#sdfootnote23sym||name="sdfootnote23anc"]](%%)^^
  While the VTL Transformations are defined in term of Dataflow definitions, they are assumed to be executed on instances of such Dataflows, provided at runtime to the VTL engine (the mechanism for identifying the instances to be processed are not part of the VTL specifications and depend on the implementation of the VTL-based systems). As already said, the SDMX Datasets are instances of SDMX Dataflows, therefore a VTL Transformation defined on some SDMX Dataflows can be applied on some corresponding SDMX Datasets.
@@ -206,28 +206,32 @@
  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. When transforming **from SDMX to VTL**, this method consists in leaving the components unchanged and maintaining their names and roles, according to the following table:
--(% style="width:529.294px" %)
--|(% style="width:151px" %)**SDMX**|(% style="width:375px" %)**VTL**
--|(% style="width:151px" %)Dimension|(% style="width:375px" %)(Simple) Identifier
--|(% style="width:151px" %)TimeDimension|(% style="width:375px" %)(Time) Identifier
--|(% style="width:151px" %)Measure|(% style="width:375px" %)Measure
--|(% style="width:151px" %)DataAttribute|(% style="width:375px" %)Attribute
++|**SDMX**|**VTL**
++|Dimension|(Simple) Identifier
++|TimeDimension|(Time) Identifier
++[[image:SDMX 3-0-0 SECTION 6 FINAL-1.0_en_59eee18f.gif||alt="Shape4" height="1" width="192"]]
++
++|Measure|Measure
++|DataAttribute|Attribute
++
  The SDMX DataAttributes, in VTL they are all considered "at data point / observation level" (i.e. dependent on all the VTL Identifiers), because VTL does not have the SDMX AttributeRelationships, which defines the construct to which the DataAttribute is related (e.g. observation, dimension or set or group of dimensions, whole data set).
--With the Basic mapping, one SDMX observation{{footnote}}Here an SDMX observation is meant to correspond to one combination of values of the DimensionComponents.{{/footnote}} generates one VTL data point.
++With the Basic mapping, one SDMX observation^^27^^ generates one VTL data point.
--==== 12.3.3.2 Pivot Mapping ====
++**12.3.3.2 Pivot Mapping**
  An alternative mapping method from SDMX to VTL is the **Pivot **mapping, which makes sense and is different from the Basic method only for the SDMX data structures that contain a Dimension that plays the role of measure dimension (like in SDMX 2.1) and just one Measure. Through this method, these structures can be mapped to multimeasure VTL data structures. Besides that, a user may choose to use any Dimension acting as a list of Measures (e.g., a Dimension with indicators), either by considering the “Measure” role of a Dimension, or at will using any coded Dimension. Of course, in SDMX 3.0, this can only work when only one Measure is defined in the DSD.
--In SDMX 2.1 the MeasureDimension was a subclass of DimensionComponent like Dimension and TimeDimension. In the current SDMX version, this subclass does not exist anymore, however a Dimension can have the role of measure dimension (i.e. a Dimension that contributes to the identification of the measures). In SDMX 2.1 a DataStructure could have zero or one MeasureDimensions, in the current version of the standard, from zero to many Dimension may have the role of measure dimension. Hereinafter a Dimension that plays the role of measure dimension is referenced for simplicity as “MeasureDimension“, i.e. maintaining the capital letters and the courier font even if the MeasureDimension is not anymore a class in the SDMX Information Model of the current SDMX version. For the sake of simplicity, the description below considers just one Dimension having the role of MeasureDimension (i.e., the more simple and common case). Nevertheless, it maintains its validity also if in the DataStructure there are more dimension with the role of MeasureDimensions: in this case what is said about the MeasureDimension must be applied to the combination of all the MeasureDimensions considered as a joint variable{{footnote}}E.g., if in the data structure there exist 3 Dimensions C,D,E having the role of MeasureDimension, they should be considered as a joint MeasureDimension Z=(C,D,E); therefore when the description says “each possible value Cj of the MeasureDimension …” it means “each possible combination of values (Cj, Dk, Ew) of the joint MeasureDimension Z=(C,D,E)”.{{/footnote}}.
++In SDMX 2.1 the MeasureDimension was a subclass of DimensionComponent like Dimension and TimeDimension. In the current SDMX version, this subclass does not exist anymore, however a Dimension can have the role of measure dimension (i.e. a Dimension that contributes to the identification of the measures). In SDMX 2.1 a DataStructure could have zero or one MeasureDimensions, in the current version of the standard, from zero to many Dimension may have the role of measure dimension. Hereinafter a Dimension that plays the role of measure dimension is referenced for simplicity as “MeasureDimension“, i.e. maintaining the capital letters and the courier font even if the MeasureDimension is not anymore a class in the SDMX Information Model of the current SDMX version. For the sake of simplicity, the description below considers just one Dimension having the role of MeasureDimension (i.e., the more simple and common case). Nevertheless, it maintains its validity also if in the DataStructure there are more dimension with the role of MeasureDimensions: in this case what is said about the MeasureDimension must be applied to the combination of all the
++MeasureDimensions considered as a joint variable^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^24^^>>path:#sdfootnote24sym||name="sdfootnote24anc"]](%%)^^.
++
  Among other things, the Pivot method provides also backward compatibility with the SDMX 2.1 data structures that contained a MeasureDimension.
  If applied to SDMX structures that do not contain any MeasureDimension, this method behaves like the Basic mapping (see the previous paragraph).
--Here an SDMX observation is meant to correspond to one combination of values of the DimensionComponents.
++^^27^^ Here an SDMX observation is meant to correspond to one combination of values of the DimensionComponents.
  The SDMX structures that contain a MeasureDimension are mapped as described below (this mapping is equivalent to a pivoting operation):
@@ -243,7 +243,7 @@
  AttributeRelationship is not specified (i.e. the DataAttribute does not depend on any DimensionComponent and therefore is at data set level), or if it refers to a set (or a group) of dimensions which does not include the MeasureDimension;
--*
++*
  ** Otherwise, if, according to the SDMX AttributeRelationship, the values of the DataAttribute depend on the MeasureDimension, the SDMX DataAttribute is mapped to one VTL Attribute for each possible Code of the SDMX MeasureDimension. By default, the names of the VTL Attributes are obtained by concatenating the name of the SDMX DataAttribute and the names of the correspondent Code of the MeasureDimension separated by underscore. For example, if the SDMX DataAttribute is named DA and the possible Codes of the SDMX MeasureDimension are named C1, C2, …, Cn, then the corresponding VTL Attributes will be named DA_C1, DA_C2, …, DA_Cn (if different names are desired, they can be achieved afterwards by renaming the Attributes through VTL operators).
  ** Like in the Basic mapping, the resulting VTL Attributes are considered as dependent on all the VTL identifiers (i.e. "at data point / observation level"), because VTL does not have the SDMX notion of Attribute Relationship.
@@ -385,20 +385,20 @@
  Until now it has been assumed to map one SMDX Dataflow to one VTL Data Set and vice-versa. This mapping one-to-one is not mandatory according to VTL because a VTL Data Set is meant to be a set of observations (data points) on a logical plane, having the same logical data structure and the same general meaning, independently of the possible physical representation or storage (see VTL 2.0 User Manual page 24), therefore a SDMX Dataflow can be seen either as a unique set of data observations (corresponding to one VTL Data Set) or as the union of many sets of data observations (each one corresponding to a distinct VTL Data Set).
--As a matter of fact, in some cases it can be useful to define VTL operations involving definite parts of a SDMX Dataflow instead than the whole.^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^25^^>>path:#sdfootnote25sym||name="sdfootnote25anc"]](%%)^^
++As a matter of fact, in some cases it can be useful to define VTL operations involving definite parts of a SDMX Dataflow instead than the whole.^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^25^^>>path:#sdfootnote25sym||name="sdfootnote25anc"]](%%)^^
--Therefore, in order to make the coding of VTL operations simpler when applied on parts of SDMX Dataflows, it is allowed to map distinct parts of a SDMX Dataflow to distinct VTL Data Sets according to the following rules and conventions. This kind of mapping is possible both from SDMX to VTL and from VTL to SDMX, as better explained below.^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^26^^>>path:#sdfootnote26sym||name="sdfootnote26anc"]](%%)^^
++Therefore, in order to make the coding of VTL operations simpler when applied on parts of SDMX Dataflows, it is allowed to map distinct parts of a SDMX Dataflow to distinct VTL Data Sets according to the following rules and conventions. This kind of mapping is possible both from SDMX to VTL and from VTL to SDMX, as better explained below.^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^26^^>>path:#sdfootnote26sym||name="sdfootnote26anc"]](%%)^^
  Given a SDMX Dataflow and some predefined Dimensions of its DataStructure, it is allowed to map the subsets of observations that have the same combination of values for such Dimensions to correspondent VTL datasets.
  For example, assuming that the SDMX Dataflow DF1(1.0.0) has the Dimensions INDICATOR, TIME_PERIOD and COUNTRY, and that the user declares the Dimensions INDICATOR and COUNTRY as basis for the mapping (i.e. the mapping dimensions): the observations that have the same values for INDICATOR and COUNTRY would be mapped to the same VTL dataset (and vice-versa). In practice, this kind mapping is obtained like follows:
--* For a given SDMX Dataflow, the user (VTL definer) declares the DimensionComponents on which the mapping will be based, in a given order.^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^27^^>>path:#sdfootnote27sym||name="sdfootnote27anc"]](%%)^^ Following the example above, imagine that the user declares the Dimensions INDICATOR and COUNTRY.
++* For a given SDMX Dataflow, the user (VTL definer) declares the DimensionComponents on which the mapping will be based, in a given order.^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^27^^>>path:#sdfootnote27sym||name="sdfootnote27anc"]](%%)^^ Following the example above, imagine that the user declares the Dimensions INDICATOR and COUNTRY.
  * The VTL Data Set is given a name using a special notation also called “ordered concatenation” and composed of the following parts:
  ** The reference to the SDMX Dataflow (expressed according to the rules described in the previous paragraphs, i.e. URN, abbreviated URN or another alias); for example DF(1.0.0);
--** a slash (“/”) as a separator; ^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^28^^>>path:#sdfootnote28sym||name="sdfootnote28anc"]](%%)^^
++** a slash (“/”) as a separator; ^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^28^^>>path:#sdfootnote28sym||name="sdfootnote28anc"]](%%)^^
--The reference to a specific part of the SDMX Dataflow above, expressed as the concatenation of the values that the SDMX DimensionComponents declared above must have, separated by dots (“.”) and written in the order in which these DimensionComponents are defined^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^29^^>>path:#sdfootnote29sym||name="sdfootnote29anc"]](%%)^^. For example POPULATION.USA would mean that such a VTL Data Set is mapped to the SDMX observations for which the dimension //INDICATOR// is equal to POPULATION and the dimension //COUNTRY// is equal to USA.
++The reference to a specific part of the SDMX Dataflow above, expressed as the concatenation of the values that the SDMX DimensionComponents declared above must have, separated by dots (“.”) and written in the order in which these DimensionComponents are defined^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^29^^>>path:#sdfootnote29sym||name="sdfootnote29anc"]](%%)^^. For example POPULATION.USA would mean that such a VTL Data Set is mapped to the SDMX observations for which the dimension //INDICATOR// is equal to POPULATION and the dimension //COUNTRY// is equal to USA.
  In the VTL Transformations, this kind of dataset name must be referenced between single quotes because the slash (“/”) is not a regular character according to the VTL rules.
@@ -414,7 +414,7 @@
  Let us now analyse the different meaning of this kind of mapping in the two mapping directions, i.e. from SDMX to VTL and from VTL to SDMX.
--As already said, the mapping from SDMX to VTL happens when the SDMX dataflows are operand of VTL Transformations, instead the mapping from VTL to SDMX happens when the VTL Data Sets that is result of Transformations^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^30^^>>path:#sdfootnote30sym||name="sdfootnote30anc"]](%%)^^ need to be treated as SDMX objects. This kind of mapping can be applied independently in the two directions and the Dimensions on which the mapping is based can be different in the two directions: these Dimensions are defined in the ToVtlSpaceKey and in the FromVtlSpaceKey classes respectively.
++As already said, the mapping from SDMX to VTL happens when the SDMX dataflows are operand of VTL Transformations, instead the mapping from VTL to SDMX happens when the VTL Data Sets that is result of Transformations^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^30^^>>path:#sdfootnote30sym||name="sdfootnote30anc"]](%%)^^ need to be treated as SDMX objects. This kind of mapping can be applied independently in the two directions and the Dimensions on which the mapping is based can be different in the two directions: these Dimensions are defined in the ToVtlSpaceKey and in the FromVtlSpaceKey classes respectively.
  First, let us see what happens in the __mapping direction from SDMX to VTL__, i.e. when parts of a SDMX Dataflow (e.g. DF1(1.0.0)) need to be mapped to distinct VTL Data Sets that are operand of some VTL Transformations.
@@ -422,7 +422,7 @@
  SDMX Dataflow having INDICATOR=//INDICATORvalue //and COUNTRY=// COUNTRYvalue//. For example, the VTL dataset ‘DF1(1.0.0)/POPULATION.USA’ would contain all the observations of DF1(1.0.0) having INDICATOR = POPULATION and COUNTRY = USA.
--In order to obtain the data structure of these VTL Data Sets from the SDMX one, it is assumed that the SDMX DimensionComponents on which the mapping is based are dropped, i.e. not maintained in the VTL data structure; this is possible because their values are fixed for each one of the invoked VTL Data Sets^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^31^^>>path:#sdfootnote31sym||name="sdfootnote31anc"]](%%)^^. After that, the mapping method from SDMX to VTL specified for the Dataflow DF1(1.0.0) is applied (i.e.
++In order to obtain the data structure of these VTL Data Sets from the SDMX one, it is assumed that the SDMX DimensionComponents on which the mapping is based are dropped, i.e. not maintained in the VTL data structure; this is possible because their values are fixed for each one of the invoked VTL Data Sets^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^31^^>>path:#sdfootnote31sym||name="sdfootnote31anc"]](%%)^^. After that, the mapping method from SDMX to VTL specified for the Dataflow DF1(1.0.0) is applied (i.e.
  basic, pivot …).
@@ -442,7 +442,7 @@
  … … …
--In fact the VTL operator “sub” has exactly the same behaviour. Therefore, mapping different parts of a SDMX Dataflow to different VTL Data Sets in the direction from SDMX to VTL through the ordered concatenation notation is equivalent to a proper use of the operator “**sub**” on such a Dataflow. ^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^32^^>>path:#sdfootnote32sym||name="sdfootnote32anc"]](%%)^^
++In fact the VTL operator “sub” has exactly the same behaviour. Therefore, mapping different parts of a SDMX Dataflow to different VTL Data Sets in the direction from SDMX to VTL through the ordered concatenation notation is equivalent to a proper use of the operator “**sub**” on such a Dataflow. ^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^32^^>>path:#sdfootnote32sym||name="sdfootnote32anc"]](%%)^^
  In the direction from SDMX to VTL it is allowed to omit the value of one or more
@@ -470,12 +470,12 @@
  Dataflow DF2(1.0.0) having the Dimensions TIME_PERIOD, INDICATOR, and COUNTRY and that such a programmer finds it convenient to calculate separately the parts of DF2(1.0.0) that have different combinations of values for INDICATOR and COUNTRY:
--* each part is calculated as a VTL derived Data Set, result of a dedicated VTL Transformation; ^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^33^^>>path:#sdfootnote33sym||name="sdfootnote33anc"]](%%)^^
--* the data structure of all these VTL Data Sets has the TIME_PERIOD identifier and does not have the INDICATOR and COUNTRY identifiers.^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^34^^>>path:#sdfootnote34sym||name="sdfootnote34anc"]](%%)^^
++* each part is calculated as a VTL derived Data Set, result of a dedicated VTL Transformation; ^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^33^^>>path:#sdfootnote33sym||name="sdfootnote33anc"]](%%)^^
++* the data structure of all these VTL Data Sets has the TIME_PERIOD identifier and does not have the INDICATOR and COUNTRY identifiers.^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^34^^>>path:#sdfootnote34sym||name="sdfootnote34anc"]](%%)^^
--Under these hypothesis, such derived VTL Data Sets can be mapped to DF2(1.0.0) by declaring the DimensionComponents INDICATOR and COUNTRY as mapping dimensions^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^35^^>>path:#sdfootnote35sym||name="sdfootnote35anc"]](%%)^^.
++Under these hypothesis, such derived VTL Data Sets can be mapped to DF2(1.0.0) by declaring the DimensionComponents INDICATOR and COUNTRY as mapping dimensions^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^35^^>>path:#sdfootnote35sym||name="sdfootnote35anc"]](%%)^^.
--The corresponding VTL Transformations, assuming that the result needs to be persistent, would be of this kind:^^ [[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^36^^>>path:#sdfootnote36sym||name="sdfootnote36anc"]](%%)^^
++The corresponding VTL Transformations, assuming that the result needs to be persistent, would be of this kind:^^ [[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^36^^>>path:#sdfootnote36sym||name="sdfootnote36anc"]](%%)^^
  ‘DF2(1.0.0)/INDICATORvalue.COUNTRYvalue’ <- expression
@@ -531,9 +531,9 @@
  In other words, starting from the datasets explicitly calculated through VTL (in the example ‘DF2(1.0)/GDPPERCAPITA.USA’ and so on), the first step consists in calculating other (non-persistent) VTL datasets (in the example
--DF2bis_GDPPERCAPITA_USA and so on) by adding the identifiers INDICATOR and COUNTRY with the desired values (//INDICATORvalue// and //COUNTRYvalue)//. Finally, all these non-persistent Data Sets are united and give the final result DF2(1.0)^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^37^^>>path:#sdfootnote37sym||name="sdfootnote37anc"]](%%)^^, which can be mapped one-to-one to the homonymous SDMX Dataflow having the dimension components TIME_PERIOD, INDICATOR and COUNTRY.
++DF2bis_GDPPERCAPITA_USA and so on) by adding the identifiers INDICATOR and COUNTRY with the desired values (//INDICATORvalue// and //COUNTRYvalue)//. Finally, all these non-persistent Data Sets are united and give the final result DF2(1.0)^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^37^^>>path:#sdfootnote37sym||name="sdfootnote37anc"]](%%)^^, which can be mapped one-to-one to the homonymous SDMX Dataflow having the dimension components TIME_PERIOD, INDICATOR and COUNTRY.
--Therefore, mapping different VTL datasets having the same data structure to different parts of a SDMX Dataflow, i.e. in the direction from VTL to SDMX, through the ordered concatenation notation is equivalent to a proper use of the operators “calc” and “union” on such datasets. ^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^38^^>>path:#sdfootnote38sym||name="sdfootnote38anc"]](%%)[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^39^^>>path:#sdfootnote39sym||name="sdfootnote39anc"]](%%)^^
++Therefore, mapping different VTL datasets having the same data structure to different parts of a SDMX Dataflow, i.e. in the direction from VTL to SDMX, through the ordered concatenation notation is equivalent to a proper use of the operators “calc” and “union” on such datasets. ^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^38^^>>path:#sdfootnote38sym||name="sdfootnote38anc"]](%%)[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^39^^>>path:#sdfootnote39sym||name="sdfootnote39anc"]](%%)^^
  It is worth noting that in the direction from VTL to SDMX it is mandatory to specify the value for every Dimension on which the mapping is based (in other word, in the name of the calculated VTL dataset is __not__ possible to omit the value of some of the Dimensions).
@@ -577,7 +577,7 @@
  The main difference between VTL and SDMX relies on the fact that the VTL artefacts for defining subsets of Value Domains do not exist in SDMX, therefore the VTL features for referring to predefined subsets are not available in SDMX. These artefacts are the Value Domain Subset (or Set), either enumerated or described, the Set List (list of values belonging to enumerated subsets) and the Data Set Component (aimed at defining the set of values that the Component of a Data Set can take, possibly a subset of the codes of Value Domain).
--Another difference consists in the fact that all Value Domains are considered as identifiable objects in VTL either if enumerated or not, while in SDMX the Codelist (corresponding to a VTL enumerated Value Domain) is identifiable, while the SDMX non-enumerated Representation (corresponding to a VTL non-enumerated Value Domain) is not identifiable. As a consequence, the definition of the VTL Rulesets, which in VTL can refer either to enumerated or non-enumerated value domains, in SDMX can refer only to enumerated Value Domains (i.e. to SDMX Codelists). As for the mapping between VTL variables and SDMX Concepts, it should be noted that these artefacts do not coincide perfectly. In fact, the VTL variables are represented variables, defined always on the same Value Domain (“Representation” in SDMX) independently of the data set / data structure in which they appear^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^40^^>>path:#sdfootnote40sym||name="sdfootnote40anc"]](%%)^^, while the SDMX Concepts can have different Representations in different DataStructures.^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^41^^>>path:#sdfootnote41sym||name="sdfootnote41anc"]](%%)^^ This means that one SDMX Concept can correspond to many VTL Variables, one for each representation the Concept has.
++Another difference consists in the fact that all Value Domains are considered as identifiable objects in VTL either if enumerated or not, while in SDMX the Codelist (corresponding to a VTL enumerated Value Domain) is identifiable, while the SDMX non-enumerated Representation (corresponding to a VTL non-enumerated Value Domain) is not identifiable. As a consequence, the definition of the VTL Rulesets, which in VTL can refer either to enumerated or non-enumerated value domains, in SDMX can refer only to enumerated Value Domains (i.e. to SDMX Codelists). As for the mapping between VTL variables and SDMX Concepts, it should be noted that these artefacts do not coincide perfectly. In fact, the VTL variables are represented variables, defined always on the same Value Domain (“Representation” in SDMX) independently of the data set / data structure in which they appear^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^40^^>>path:#sdfootnote40sym||name="sdfootnote40anc"]](%%)^^, while the SDMX Concepts can have different Representations in different DataStructures.^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^41^^>>path:#sdfootnote41sym||name="sdfootnote41anc"]](%%)^^ This means that one SDMX Concept can correspond to many VTL Variables, one for each representation the Concept has.
  Therefore, it is important to be aware that some VTL operations (for example the binary operations at data set level) are consistent only if the components having the same names in the operated VTL Data Sets have also the same representation (i.e. the same Value Domain as for VTL). For example, it is possible to obtain correct results from the VTL expression
@@ -1046,7 +1046,7 @@
  |N|fixed number of digits used in the preceding textual representation of the month or the day
  | |
--The default conversion, either standard or customized, can be used to deduce automatically the representation of the components of the result of a VTL Transformation. In alternative, the representation of the resulting SDMX Dataflow can be given explicitly by providing its DataStructureDefinition. In other words, the representation specified in the DSD, if available, overrides any default conversion^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^42^^>>path:#sdfootnote42sym||name="sdfootnote42anc"]](%%)^^.
++The default conversion, either standard or customized, can be used to deduce automatically the representation of the components of the result of a VTL Transformation. In alternative, the representation of the resulting SDMX Dataflow can be given explicitly by providing its DataStructureDefinition. In other words, the representation specified in the DSD, if available, overrides any default conversion^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^42^^>>path:#sdfootnote42sym||name="sdfootnote42anc"]](%%)^^.
  === 12.4.5 Null Values ===