Changes for page 12 Validation and Transformation Language (VTL)

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

From 5.15 to 5.16 From 6.1 to 6.2

From version 5.16

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

Change comment: There is no comment for this version

To version 6.1

edited by Helena
on 2025/05/16 09:09

Change comment: There is no comment for this version

Raw
Rendered

Summary

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

Details

Page properties

Content

@@ -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 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.{{footnote}}In case the ordered concatenation notation is used, the VTL Transformation described above, e.g. ‘DF1(1.0)/POPULATION.USA’ := DF1(1.0) [ sub INDICATOR=“POPULATION”, COUNTRY=“USA”], is implicitly executed. In order to test the overall compliance of the VTL program to the VTL consistency rules, it has to be considered as part of the VTL program even if it is not explicitly coded.{{/footnote}}
  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 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 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;{{footnote}}If the whole DF2(1.0) is calculated by means of just one VTL Transformation, then the mapping between the SDMX Dataflow and the corresponding VTL dataset is one-to-one and this kind of mapping (one SDMX Dataflow to many VTL datasets) does not apply.{{/footnote}}
++* the data structure of all these VTL Data Sets has the TIME_PERIOD identifier and does not have the INDICATOR and COUNTRY identifiers.{{footnote}}This is possible as each VTL dataset corresponds to one particular combination of values of INDICATOR and COUNTRY.{{/footnote}}
--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 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{{footnote}}The mapping dimensions are defined as FromVtlSpaceKeys of the FromVtlSuperSpace of the VtlDataflowMapping relevant to DF2(1.0).{{/footnote}}.
--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 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:{{footnote}}the symbol of the VTL persistent assignment is used (<-){{/footnote}}
  ‘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 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){{footnote}}The result is persistent in this example but it can be also non persistent if needed.{{/footnote}}, 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 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 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.{{footnote}}In case the ordered concatenation notation from VTL to SDMX is used, the set of Transformations described above is implicitly performed; therefore, in order to test the overall compliance of the VTL program to the VTL consistency rules, these implicit Transformations have to be considered as part of the VTL program even if they are not explicitly coded.{{/footnote}}
  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).
@@ -541,52 +541,51 @@
  With reference to the VTL “model for Variables and Value domains”, the following additional mappings have to be considered:
--|VTL|SDMX
--|**Data Set Component**|Although this abstraction exists in SDMX, it does not have an explicit definition and correspond to a Component (either a DimensionComponent or a Measure or a DataAttribute) belonging to one specific Dataflow^^43^^
--|**Represented Variable**|(((
++(% style="width:1170.29px" %)
++|**VTL**|(% style="width:754px" %)**SDMX**
++|**Data Set Component**|(% style="width:754px" %)Although this abstraction exists in SDMX, it does not have an explicit definition and correspond to a Component (either a DimensionComponent or a Measure or a DataAttribute) belonging to one specific Dataflow{{footnote}}Through SDMX Constraints, it is possible to specify the values that a Component of a Dataflow can assume.{{/footnote}}
++|**Represented Variable**|(% style="width:754px" %)(((
  **Concept** with a definite
  Representation
  )))
--|**Value Domain**|(((
++|**Value Domain**|(% style="width:754px" %)(((
  **Representation** (see the Structure
  Pattern in the Base Package)
  )))
--|**Enumerated Value Domain / Code List**|**Codelist**
--|**Code**|(((
++|**Enumerated Value Domain / Code List**|(% style="width:754px" %)**Codelist**
++|**Code**|(% style="width:754px" %)(((
  **Code** (for enumerated
  DimensionComponent, Measure, DataAttribute)
  )))
--|**Described Value Domain**|(((
--non-enumerated** &nbsp;&nbsp;&nbsp;Representation**
++|**Described Value Domain**|(% style="width:754px" %)(((
++non-enumerated** Representation**
  (having Facets / ExtendedFacets, see the Structure Pattern in the Base Package)
  )))
--|**Value**|Although this abstraction exists in SDMX, it does not have an explicit definition and correspond to a **Code** of a Codelist (for enumerated Representations) or
--| |(((
--to a valid **value &nbsp;&nbsp;&nbsp;**(for non-enumerated** &nbsp;&nbsp;&nbsp;**
--
--Representations)
++|**Value**|(% style="width:754px" %)Although this abstraction exists in SDMX, it does not have an explicit definition and correspond to a **Code** of a Codelist (for enumerated Representations) or
++| |(% style="width:754px" %)(((
++to a valid **value **(for non-enumerated** **Representations)
  )))
--|**Value Domain Subset / Set**|This abstraction does not exist in SDMX
--|**Enumerated Value Domain Subset / Enumerated Set**|This abstraction does not exist in SDMX
--|**Described Value Domain Subset / Described Set**|This abstraction does not exist in SDMX
--|**Set list**|This abstraction does not exist in SDMX
++|**Value Domain Subset / Set**|(% style="width:754px" %)This abstraction does not exist in SDMX
++|**Enumerated Value Domain Subset / Enumerated Set**|(% style="width:754px" %)This abstraction does not exist in SDMX
++|**Described Value Domain Subset / Described Set**|(% style="width:754px" %)This abstraction does not exist in SDMX
++|**Set list**|(% style="width:754px" %)This abstraction does not exist in SDMX
  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 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 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{{footnote}}By using represented variables, VTL can assume that data structures having the same variables as identifiers can be composed one another because the correspondent values can match.{{/footnote}}, while the SDMX Concepts can have different Representations in different DataStructures.{{footnote}}A Concept becomes a Component in a DataStructureDefinition, and Components can have different LocalRepresentations in different DataStructureDefinitions, also overriding the (possible) base representation of the Concept.{{/footnote}} 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
--DS_c := DS_a + DS_b (where DS_a, DS_b, DS_c are VTL Data Sets) if the matching components in DS_a and DS_b (e.g. ref_date, geo_area, sector …) refer to the same general representation. In simpler words, DS_a and DS_b must use the same values/codes (for ref_date, geo_area, sector … ), otherwise the relevant values would not match and the result of the operation would be wrong.
++DS_c := DS_a + DS_b (where DS_a, DS_b, DS_c are VTL Data Sets)
++if the matching components in DS_a and DS_b (e.g. ref_date, geo_area, sector …) refer to the same general representation. In simpler words, DS_a and DS_b must use the same values/codes (for ref_date, geo_area, sector … ), otherwise the relevant values would not match and the result of the operation would be wrong.
++
  As mentioned, the property above is not enforced by construction in SDMX, and different representations of the same Concept can be not compatible one another (for example, it may happen that geo_area is represented by ISO-alpha-3 codes in DS_a and by ISO alpha-2 codes in DS_b). Therefore, it will be up to the definer of VTL
--[[image:SDMX 3-0-0 SECTION 6 FINAL-1.0_en_59eee18f.gif||alt="Shape5" height="1" width="192"]]
--
  Transformations to ensure that the VTL expressions are consistent with the actual representations of the correspondent SDMX Concepts.
  It remains up to the SDMX-VTL definer also the assurance of the consistency between a VTL Ruleset defined on Variables and the SDMX Components on which the Ruleset is applied. In fact, a VTL Ruleset is expressed by means of the values of the Variables (i.e. SDMX Concepts), i.e. assuming definite representations for them (e.g. ISOalpha-3 for country). If the Ruleset is applied to SDMX Components that have the same name of the Concept they refer to but different representations (e.g. ISO-alpha-2 for country), the Ruleset cannot work properly.
@@ -601,7 +601,8 @@
  [[image:SDMX 3-0-0 SECTION 6 FINAL-1.0_en_e3df33ae.png||height="543" width="483"]]
--==== Figure 22 – VTL Data Types ====
++(% class="wikigeneratedid" id="HFigure222013VTLDataTypes" %)
++**Figure 22 – VTL Data Types**
  The VTL scalar types are in turn subdivided in basic scalar types, which are elementary (not defined in term of other data types) and Value Domain and Set scalar types, which are defined in terms of the basic scalar types.
@@ -608,131 +608,12 @@
  The VTL basic scalar types are listed below and follow a hierarchical structure in terms of supersets/subsets (e.g. "scalar" is the superset of all the basic scalar types):
++**Figure 23 – VTL Basic Scalar Types**
  (((
--//n//
--
--//a//
--
--//e//
--
--//l//
--
--//o//
--
--//o//
--
--//B//
--
--//n//
--
--//o//
--
--//i//
--
--//t//
--
--//a//
--
--//r//
--
--//u//
--
--//D//
--
--//d//
--
--//o//
--
--//i//
--
--//r//
--
--//e//
--
--//p//
--
--//_//
--
--//e//
--
--//m//
--
--//i//
--
--//T//
--
--//e//
--
--//t//
--
--//a//
--
--//D//
--
--//e//
--
--//m//
--
--//i//
--
--//T//
--
--//r//
--
--//e//
--
--//g//
--
--//e//
--
--//t//
--
--//n//
--
--//I//
--
--//r//
--
--//e//
--
--//b//
--
--//m//
--
--//u//
--
--//N//
--
--//g//
--
--//n//
--
--//i//
--
--//r//
--
--//t//
--
--//S//
--
--//r//
--
--//a//
--
--//l//
--
--//a//
--
--//c//
--
--//S//
--
--[[image:SDMX 3-0-0 SECTION 6 FINAL-1.0_en_82d45833.gif||alt="Shape6" height="231" width="184"]]
++
  )))
--==== Figure 23 – VTL Basic Scalar Types ====
--
  === 12.4.2 VTL basic scalar types and SDMX data types ===
  The VTL assumes that a basic scalar type has a unique internal representation and can have more external representations.
@@ -755,204 +755,159 @@
  The following table describes the default mapping for converting from the SDMX data types to the VTL basic scalar types.
--|SDMX data type (BasicComponentDataType)|Default VTL basic scalar type
--|(((
++(% style="width:823.294px" %)
++|(% style="width:509px" %)**SDMX data type (BasicComponentDataType)**|(% style="width:312px" %)**Default VTL basic scalar type**
++|(% style="width:509px" %)(((
  String
--
  (string allowing any character)
--)))|string
--|(((
++)))|(% style="width:312px" %)string
++|(% style="width:509px" %)(((
  Alpha
--
  (string which only allows A-z)
--)))|string
--|(((
++)))|(% style="width:312px" %)string
++|(% style="width:509px" %)(((
  AlphaNumeric
--
  (string which only allows A-z and 0-9)
--)))|string
--|(((
++)))|(% style="width:312px" %)string
++|(% style="width:509px" %)(((
  Numeric
--
  (string which only allows 0-9, but is not numeric so that is can having leading zeros)
--)))|string
--|(((
++)))|(% style="width:312px" %)string
++|(% style="width:509px" %)(((
  BigInteger
--
  (corresponds to XML Schema xs:integer datatype; infinite set of integer values)
--)))|integer
--|(((
++)))|(% style="width:312px" %)integer
++|(% style="width:509px" %)(((
  Integer
--
--(corresponds to XML Schema xs:int datatype; between -2147483648 and +2147483647
--
--(inclusive))
--)))|integer
--|(((
++(corresponds to XML Schema xs:int datatype; between -2147483648 and +2147483647 (inclusive))
++)))|(% style="width:312px" %)integer
++|(% style="width:509px" %)(((
  Long
--
--(corresponds to XML Schema xs:long datatype; between -9223372036854775808 and
--
--+9223372036854775807 (inclusive))
--)))|integer
--|(((
++(corresponds to XML Schema xs:long datatype; between -9223372036854775808 and +9223372036854775807 (inclusive))
++)))|(% style="width:312px" %)integer
++|(% style="width:509px" %)(((
  Short
--
  (corresponds to XML Schema xs:short datatype; between -32768 and -32767 (inclusive))
--)))|integer
--|Decimal (corresponds to XML Schema xs:decimal datatype; subset of real numbers that can be represented as decimals)|number
--|(((
++)))|(% style="width:312px" %)integer
++|(% style="width:509px" %)Decimal (corresponds to XML Schema xs:decimal datatype; subset of real numbers that can be represented as decimals)|(% style="width:312px" %)number
++|(% style="width:509px" %)(((
  Float
--
  (corresponds to XML Schema xs:float datatype; patterned after the IEEE single-precision 32-bit floating point type)
--)))|number
--|(((
++)))|(% style="width:312px" %)number
++|(% style="width:509px" %)(((
  Double
--
  (corresponds to XML Schema xs:double datatype; patterned after the IEEE double-precision 64-bit floating point type)
--)))|number
--|(((
++)))|(% style="width:312px" %)number
++|(% style="width:509px" %)(((
  Boolean
++(corresponds to the XML Schema xs:boolean datatype; support the mathematical concept of binary-valued logic: {true, false})
++)))|(% style="width:312px" %)boolean
--(corresponds to the XML Schema xs:boolean datatype; support the mathematical concept of
--
--binary-valued logic: {true, false})
--)))|boolean
--
--| |(% colspan="2" %)(((
++(% style="width:822.294px" %)
++|(% colspan="2" style="width:507px" %)(((
  URI
--
  (corresponds to the XML Schema xs:anyURI; absolute or relative Uniform Resource Identifier Reference)
--)))|(% colspan="2" %)string
--| |(% colspan="2" %)(((
++)))|(% colspan="1" style="width:311px" %)string
++|(% colspan="2" style="width:507px" %)(((
  Count
--
  (an integer following a sequential pattern, increasing by 1 for each occurrence)
--)))|(% colspan="2" %)integer
--| |(% colspan="2" %)(((
++)))|(% colspan="1" style="width:311px" %)integer
++|(% colspan="2" style="width:507px" %)(((
  InclusiveValueRange
--
  (decimal number within a closed interval, whose bounds are specified in the SDMX representation by the facets minValue and maxValue)
--)))|(% colspan="2" %)number
--| |(% colspan="2" %)(((
++)))|(% colspan="1" style="width:311px" %)number
++|(% colspan="2" style="width:507px" %)(((
  ExclusiveValueRange
--
  (decimal number within an open interval, whose bounds are specified in the SDMX representation by the facets minValue and maxValue)
--)))|(% colspan="2" %)number
--| |(% colspan="2" %)(((
++)))|(% colspan="1" style="width:311px" %)number
++|(% colspan="2" style="width:507px" %)(((
  Incremental
--
  (decimal number the increased by a specific interval (defined by the interval facet), which is typically enforced outside of the XML validation)
--)))|(% colspan="2" %)number
--| |(% colspan="2" %)(((
++)))|(% colspan="1" style="width:311px" %)number
++|(% colspan="2" style="width:507px" %)(((
  ObservationalTimePeriod
--
  (superset of StandardTimePeriod and TimeRange)
--)))|(% colspan="2" %)time
--| |(% colspan="2" %)(((
++)))|(% colspan="1" style="width:311px" %)time
++|(% colspan="2" style="width:507px" %)(((
  StandardTimePeriod
--
--(superset of BasicTimePeriod and
--
--ReportingTimePeriod)
--)))|(% colspan="2" %)time
--| |(% colspan="2" %)(((
++(superset of BasicTimePeriod and ReportingTimePeriod)
++)))|(% colspan="1" style="width:311px" %)time
++|(% colspan="2" style="width:507px" %)(((
  BasicTimePeriod
--
  (superset of GregorianTimePeriod and DateTime)
--)))|(% colspan="2" %)date
--| |(% colspan="2" %)(((
++)))|(% colspan="1" style="width:311px" %)date
++|(% colspan="2" style="width:507px" %)(((
  GregorianTimePeriod
--
  (superset of GregorianYear, GregorianYearMonth, and GregorianDay)
--)))|(% colspan="2" %)date
--| |(% colspan="2" %)GregorianYear (YYYY)|(% colspan="2" %)date
--| |(% colspan="2" %)GregorianYearMonth / GregorianMonth (YYYY-MM)|(% colspan="2" %)date
--| |(% colspan="2" %)GregorianDay (YYYY-MM-DD)|(% colspan="2" %)date
--| |(% colspan="2" %)(((
++)))|(% colspan="1" style="width:311px" %)date
++|(% colspan="2" style="width:507px" %)GregorianYear (YYYY)|(% colspan="1" style="width:311px" %)date
++|(% colspan="2" style="width:507px" %)GregorianYearMonth / GregorianMonth (YYYY-MM)|(% colspan="1" style="width:311px" %)date
++|(% colspan="2" style="width:507px" %)GregorianDay (YYYY-MM-DD)|(% colspan="1" style="width:311px" %)date
++|(% colspan="2" style="width:507px" %)(((
  ReportingTimePeriod
--
--(superset of RepostingYear, ReportingSemester,
--
--ReportingTrimester, ReportingQuarter,
--
--ReportingMonth, ReportingWeek, ReportingDay)
--)))|(% colspan="2" %)time_period
--| |(% colspan="2" %)(((
++(superset of RepostingYear, ReportingSemester, ReportingTrimester, ReportingQuarter, ReportingMonth, ReportingWeek, ReportingDay)
++)))|(% colspan="1" style="width:311px" %)time_period
++|(% colspan="2" style="width:507px" %)(((
  ReportingYear
--
  (YYYY-A1 – 1 year period)
--)))|(% colspan="2" %)time_period
--| |(% colspan="2" %)(((
++)))|(% colspan="1" style="width:311px" %)time_period
++|(% colspan="2" style="width:507px" %)(((
  ReportingSemester
--
  (YYYY-Ss – 6 month period)
--)))|(% colspan="2" %)time_period
--| |(% colspan="2" %)(((
++)))|(% colspan="1" style="width:311px" %)time_period
++|(% colspan="2" style="width:507px" %)(((
  ReportingTrimester
--
  (YYYY-Tt – 4 month period)
--)))|(% colspan="2" %)time_period
--| |(% colspan="2" %)(((
++)))|(% colspan="1" style="width:311px" %)time_period
++|(% colspan="2" style="width:507px" %)(((
  ReportingQuarter
--
  (YYYY-Qq – 3 month period)
--)))|(% colspan="2" %)time_period
--| |(% colspan="2" %)(((
++)))|(% colspan="1" style="width:311px" %)time_period
++|(% colspan="2" style="width:507px" %)(((
  ReportingMonth
--
  (YYYY-Mmm – 1 month period)
--)))|(% colspan="2" %)time_period
--| |(% colspan="2" %)ReportingWeek|(% colspan="2" %)time_period
--| |(% colspan="2" %) |(% colspan="2" %)
--| |(% colspan="2" %) |(% colspan="2" %)
--|(% colspan="2" %)(YYYY-Www – 7 day period; following ISO 8601 definition of a week in a year)|(% colspan="2" %) |
--|(% colspan="2" %)(((
++)))|(% colspan="1" style="width:311px" %)time_period
++|(% colspan="2" style="width:507px" %)ReportingWeek|(% colspan="1" style="width:311px" %)time_period
++|(% colspan="1" style="width:507px" %)(YYYY-Www – 7 day period; following ISO 8601 definition of a week in a year)|(% colspan="2" style="width:312px" %)
++|(% colspan="1" style="width:507px" %)(((
  ReportingDay
--
  (YYYY-Dddd – 1 day period)
--)))|(% colspan="2" %)time_period|
--|(% colspan="2" %)(((
++)))|(% colspan="2" style="width:312px" %)time_period
++|(% colspan="1" style="width:507px" %)(((
  DateTime
--
  (YYYY-MM-DDThh:mm:ss)
--)))|(% colspan="2" %)date|
--|(% colspan="2" %)(((
++)))|(% colspan="2" style="width:312px" %)date
++|(% colspan="1" style="width:507px" %)(((
  TimeRange
--
  (YYYY-MM-DD(Thh:mm:ss)?/<duration>)
--)))|(% colspan="2" %)time|
--|(% colspan="2" %)(((
++)))|(% colspan="2" style="width:312px" %)time
++|(% colspan="1" style="width:507px" %)(((
  Month
--
  (~-~-MM; speicifies a month independent of a year; e.g. February is black history month in the United States)
--)))|(% colspan="2" %)string|
--|(% colspan="2" %)(((
++)))|(% colspan="2" style="width:312px" %)string
++|(% colspan="1" style="width:507px" %)(((
  MonthDay
--
  (~-~-MM-DD; specifies a day within a month independent of a year; e.g. Christmas is December 25^^th^^; used to specify reporting year start day)
--)))|(% colspan="2" %)string|
--|(% colspan="2" %)(((
++)))|(% colspan="2" style="width:312px" %)string
++|(% colspan="1" style="width:507px" %)(((
  Day
--
  (~-~--DD; specifies a day independent of a month or year; e.g. the 15^^th^^ is payday)
--)))|(% colspan="2" %)string|
--|(% colspan="2" %)(((
++)))|(% colspan="2" style="width:312px" %)string
++|(% colspan="1" style="width:507px" %)(((
  Time
--
  (hh:mm:ss; time independent of a date; e.g. coffee break is at 10:00 AM)
--)))|(% colspan="2" %)string|
--|(% colspan="2" %)(((
++)))|(% colspan="2" style="width:312px" %)string
++|(% colspan="1" style="width:507px" %)(((
  Duration
--
  (corresponds to XML Schema xs:duration datatype)
--)))|(% colspan="2" %)duration|
--|(% colspan="2" %)XHTML|(% colspan="2" %)Metadata type – not applicable|
--|(% colspan="2" %)KeyValues|(% colspan="2" %)Metadata type – not applicable|
--|(% colspan="2" %)IdentifiableReference|(% colspan="2" %)Metadata type – not applicable|
--|(% colspan="2" %)DataSetReference|(% colspan="2" %)Metadata type – not applicable|
++)))|(% colspan="2" style="width:312px" %)duration
++|(% colspan="1" style="width:507px" %)XHTML|(% colspan="2" style="width:312px" %)Metadata type – not applicable
++|(% colspan="1" style="width:507px" %)KeyValues|(% colspan="2" style="width:312px" %)Metadata type – not applicable
++|(% colspan="1" style="width:507px" %)IdentifiableReference|(% colspan="2" style="width:312px" %)Metadata type – not applicable
++|(% colspan="1" style="width:507px" %)DataSetReference|(% colspan="2" style="width:312px" %)Metadata type – not applicable
--==== Figure 14 – Mappings from SDMX data types to VTL Basic Scalar Types ====
++(% class="wikigeneratedid" id="HFigure142013MappingsfromSDMXdatatypestoVTLBasicScalarTypes" %)
++**Figure 14 – Mappings from SDMX data types to VTL Basic Scalar Types**
  When VTL takes in input SDMX artefacts, it is assumed that a type conversion according to the table above always happens. In case a different VTL basic scalar type is desired, it can be achieved in the VTL program taking in input the default VTL basic scalar type above and applying to it the VTL type conversion features (see the implicit and explicit type conversion and the "cast" operator in the VTL Reference Manual).
@@ -960,39 +960,32 @@
  The following table describes the default conversion from the VTL basic scalar types to the SDMX data types .
--|(((
--VTL basic
--
--scalar type
--)))|(((
--Default SDMX data type
--
--(BasicComponentDataType
--
--)
--)))|Default output format
--|String|String|Like XML (xs:string)
--|Number|Float|Like XML (xs:float)
--|Integer|Integer|Like XML (xs:int)
--|Date|DateTime|YYYY-MM-DDT00:00:00Z
--|Time|StandardTimePeriod|<date>/<date> (as defined above)
--|time_period|(((
++(% style="width:1073.29px" %)
++|(% style="width:207px" %)(((
++**VTL basic scalar type**
++)))|(% style="width:462px" %)(((
++**Default SDMX data type (BasicComponentDataType)**
++)))|(% style="width:402px" %)**Default output format**
++|(% style="width:207px" %)String|(% style="width:462px" %)String|(% style="width:402px" %)Like XML (xs:string)
++|(% style="width:207px" %)Number|(% style="width:462px" %)Float|(% style="width:402px" %)Like XML (xs:float)
++|(% style="width:207px" %)Integer|(% style="width:462px" %)Integer|(% style="width:402px" %)Like XML (xs:int)
++|(% style="width:207px" %)Date|(% style="width:462px" %)DateTime|(% style="width:402px" %)YYYY-MM-DDT00:00:00Z
++|(% style="width:207px" %)Time|(% style="width:462px" %)StandardTimePeriod|(% style="width:402px" %)<date>/<date> (as defined above)
++|(% style="width:207px" %)time_period|(% style="width:462px" %)(((
  ReportingTimePeriod
--
  (StandardReportingPeriod)
--)))|(((
++)))|(% style="width:402px" %)(((
  YYYY-Pppp
--
  (according to SDMX )
  )))
--|Duration|Duration|(((
++|(% style="width:207px" %)Duration|(% style="width:462px" %)Duration|(% style="width:402px" %)(((
  Like XML (xs:duration)
--
  PnYnMnDTnHnMnS
  )))
--|Boolean|Boolean|Like XML (xs:boolean) with the values "true" or "false"
++|(% style="width:207px" %)Boolean|(% style="width:462px" %)Boolean|(% style="width:402px" %)Like XML (xs:boolean) with the values "true" or "false"
--==== Figure 14 – Mappings from SDMX data types to VTL Basic Scalar Types ====
++(% class="wikigeneratedid" id="HFigure142013MappingsfromSDMXdatatypestoVTLBasicScalarTypes-1" %)
++**Figure 14 – Mappings from SDMX data types to VTL Basic Scalar Types**
  In case a different default conversion is desired, it can be achieved through the CustomTypeScheme and CustomType artefacts (see also the section Transformations and Expressions of the SDMX information model).
@@ -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 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{{footnote}}The representation given in the DSD should obviously be compatible with the VTL data type.{{/footnote}}.
  === 12.4.5 Null Values ===
@@ -1064,10 +1064,8 @@
  A different format can be specified in the attribute "vtlLiteralFormat" of the CustomType artefact (see also the section Transformations and Expressions of the SDMX information model).
--Like in the case of the conversion of NULLs described in the previous paragraph, the overriding assumption is applied, for a certain VTL basic scalar type, if a value is found for the vtlLiteralFormat attribute of the CustomType of such VTL basic scalar type. The overriding assumption is applied for all the literals of a related VTL
++Like in the case of the conversion of NULLs described in the previous paragraph, the overriding assumption is applied, for a certain VTL basic scalar type, if a value is found for the vtlLiteralFormat attribute of the CustomType of such VTL basic scalar type. The overriding assumption is applied for all the literals of a related VTL TransformationScheme.
--TransformationScheme.
--
  In case a literal is operand of a VTL Cast operation, the format specified in the Cast overrides all the possible otherwise specified formats.
  {{putFootnotes/}}