Skip to Content
Version 6.1 by Helena on 2025/05/15 11:36
Show last authors
1 {{box title="**Contents**"}}
2 {{toc/}}
3 {{/box}}
4
5 == 15.1 Introduction ==
6
7 This SDMX model package supports the definition of Transformations, which are algorithms to calculate new data starting from already existing ones, written using the Validation and Transformation Language (VTL){{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}}.
8
9 The purpose of this model package is to enable the:
10
11 * definition of validation and transformation algorithms by means of VTL, in order to specify how to calculate new SDMX data from existing ones;
12 * 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 * execution of VTL algorithms, either interpreting the VTL transformations or translating them in whatever other computer language is deemed as appropriate;
14
15 This model package does not explain the VTL language or any of the content published in the VTL guides. Rather, this is an illustration of the SDMX classes and attributes that allow defining VTL transformations applied to SDMX artefacts.
16
17 The SDMX model represented below is consistent with the VTL 2.0 specification. However, the former uses the SDMX terminology and is a model at technical level (from which the SDMX implementation artefacts for defining VTL transformations are built), whereas the latter uses the VTL terminology and is at conceptual level. The guidelines for mapping these terminologies and using the VTL in the SDMX context can be found in a dedicated chapter (“//Validation and Transformation Language//”) of the Section 6 of the SDMX Standards (“//SDMX Technical Notes//”), often referenced below.
18
19 == 15.2 Model - Inheritance view ==
20
21 === 15.2.1 Class Diagram ===
22
23 [[image:SDMX 3-0-0 SECTION 2 FINAL-1.0 (1)_en_c8abccb2.jpg||height="569" width="610"]]
24
25 **Figure 47: Class inheritance diagram in the Transformations and Expressions Package**
26
27 === 15.2.2 Explanation of the Diagram ===
28
29 ==== 15.2.2.1 Narrative ====
30
31 The model artefacts TransformationScheme, RulesetScheme, UserDefinedOperatorScheme, NamePersonalisationScheme, CustomTypeScheme, and VtlMappingScheme inherit from ItemScheme
32
33 These schemes inherit from the //ItemScheme //and therefore have the following attributes:
34
35 id uri urn version validFrom validTo isExternalReference registryURL structureURL repositoryURL isPartial
36
37 The model artefacts Transformation, Ruleset, UserDefinedOperator, NamePersonalisation, VtlMapping, CustomType inherit the attributes and associations of Item which itself inherits from //NameableArtefact//. They have the following attributes:
38
39 id uri urn
40
41 The multi-lingual name and description are provided by the relationship to InternationalString from //NameableArtefact//.
42
43 == 15.3 Model - Relationship View ==
44
45 === 15.3.1 Class Diagram ===
46
47 [[image:SDMX 3-0-0 SECTION 2 FINAL-1.0 (1)_en_9840716.jpg||height="456" width="601"]]
48
49 **Figure 48: Relationship diagram in the Transformations and Expressions Package**
50
51 === 15.3.2 Explanation of the Diagram ===
52
53 ==== 15.3.2.1 Narrative - Overview ====
54
55 ===== **Transformation Scheme** =====
56
57 A TransformationScheme is a set of Transformations aimed at obtaining some meaningful results for the user (e.g. the validation of one or more Data Sets). This set of Transformations is meant to be executed together (in the same run) and may contain any number of Transformations in order to produce any number of results. Therefore, a TransformationScheme can be considered as a VTL program.
58
59 The TransformationScheme must include the attribute vtlVersion expressed as a string (e.g. “2.0”), as the version of the VTL determines which syntax is used in defining the transformations of the scheme.
60
61 A Transformation consists of a statement which assigns the outcome of the evaluation of a VTL expression to a result (an artefact of the VTL Information Model, which in the SDMX context can be a persistent or non-persistent Dataflow{{footnote}}Or a part of a Dataflow, see also the chapter “Validation and Transformation Language” of the Section 6 of the SDMX Standards (“SDMX Technical Notes”), paragraph “Mapping dataflow subsets to distinct VTL data sets”.{{/footnote}}).
62
63 For example, assume that D1, D2 and D3 are SDMX Dataflows (called Data Sets in VTL) containing information on some goods, specifically: D3 the current stocks, D1 the stocks of the previous date, D2 the flows in the last period. A possible VTL Transformation aimed at checking the consistency between flows and stocks is the following:
64
65 Dr := If ( (D1 + D2) = D3, then "true", else "false")
66
67 In this Transformation:
68
69 Dr is the result (a new dataflow) := is an assignment operator
70
71 If((D1+D2)=D3, then "true", else "false") is the expression
72
73 D1, D2, D3 are the operands
74
75 If, ( ), +, = are VTL operators
76
77 The Transformation model artefact contains three attributes:
78
79 1. result
80
81 The left-hand side of a VTL statement, which specifies the Artefact to which the outcome of the expression is assigned. An artefact cannot be result of more than one
82
83 Transformation.
84
85 1. isPersistent
86
87 An assignment operator, which specifies also the persistency of the left-hand side. The assignment operators are two, namely ‘:=’ for non-persistent assignment (the result is non-persistent) and ‘<-’ for persistent assignment (the result is persistent).
88
89 1. expression
90
91 The right-hand side of a VTL statement, which is the expression to be evaluated. An expression consists in the invocation of VTL operators in a certain order. When an operator is invoked, for each input parameter, an actual argument is passed to the operator, which returns an actual argument for the output parameter. An expression is simply a text string written according the VTL grammar.
92
93 Because an Artefact can be the result of just one Transformation and a Transformation belongs to just one TransformationScheme, it follows also that a derived Artefact (e.g., a new Dataflow) is produced in just one TransformationScheme.
94
95 The result of a Transformation can be input of other Transformations. The VTL assumes that non-persistent results are maintained only within the same TransformationScheme in which they are produced. Therefore, a non-persistent result of a Transformation can be the operand of other Transformations of the same TransformationScheme, whereas a persistent result can be operand of transformations of any TransformationScheme{{footnote}}Provided that the VTL consistency rules are accomplished (see the “Generic Model for Transformations” in the VTL User Manual and its sub-section “Transformation Consistency”).{{/footnote}}.
96
97 The TransformationScheme has an association to zero of more RulesetScheme, zero or more UserDefinedOperatorScheme, zero or one NamePersonalisationScheme, zero or one VtlMappingScheme, and zero or one CustomTypeScheme.
98
99 The RulesetScheme, UserDefinedOperatorScheme, NamePersonalisationScheme and CustomTypeScheme have the attribute vtlVersion. Thus, a TransformationScheme using a specific version of VTL can be linked to such schemes only if they are consistent with the same VTL version.
100
101 The VtlMappingScheme associated to a TransformationScheme must contain the mappings between the references to the SDMX artefacts from the TransformationScheme and the structured identifiers of these SDMX artefacts.
102
103 ===== **Ruleset Scheme** =====
104
105 Some VTL Operators can invoke rulesets, i.e., sets of previously defined rules to be applied by the Operator. Once defined, a Ruleset is persistent and can be invoked as many times as needed. The knowledge of the rulesets’ definitions (if any) is essential for understanding the actual behaviour of the Transformation that use them: this is achieved through the RulesetScheme model artefact. The RulesetScheme is the container for one or more Ruleset.
106
107 The Ruleset model artefact contains the following attributes:
108
109 1. rulesetType – the type of the ruleset according to VTL (VTL 2.0 allows two types: “datapoint” and “hierarchical” ruleset);
110 1. rulesetScope – the VTL artefact on which the ruleset is defined; VTL 2.0 allows rulesets defined on Value Domains, which correspond to SDMX Codelists and rulesets defined on Variables, which correspond to SDMX Concepts for which a definite Representation is assumed;
111 1. rulesetDefinition – the VTL statement that defines the ruleset according to the syntax of the VTL definition language.
112
113 The RulesetScheme can have an association with zero or more VtlMappingScheme. These mappings define the correspondence between the references to the SDMX artefacts contained in the rulesetDefinition and the structured identifiers of these SDMX artefacts.
114
115 The rulesets defined on Value Domains reference Codelists. The rulesets defined on Variables reference Concepts (for which a definite Representation is assumed). In conclusion, in the VTL rulesets there can exist mappings for: Codelists and Concepts.
116
117 ===== **User Defined Operator Scheme** =====
118
119 The UserDefinedOperatorScheme is a container for zero of more UserDefinedOperator. The UserDefinedOperator is defined using VTL standard operators. This is essential for understanding the actual behaviour of the Transformations that invoke them.
120
121 The attribute operatorDefinition contains the VTL statement that defines the operator according to the syntax of the VTL definition language.
122
123 Although the VTL user defined operators are conceived to be defined on generic operands, so that the specific artefacts to be manipulated are passed as parameters at the invocation, it is also possible that they reference specific SDMX artefacts like Dataflows and Codelists. Therefore, the UserDefinedOperatorScheme can link to zero or one VtlMappingScheme, which must contain the mappings between the VTL references and the structured URN of the corresponding SDMX artefacts (see also the “//VTL mapping//” section below).
124
125 The definition of a UserDefinedOperator can also make use of VTL rulesets; therefore, the UserDefinedOperatorScheme can link to zero, one or more RulesetScheme**, which** must contain the definition of these Rulesets (see also the “//Ruleset Scheme//” section above).
126
127 ===== **Name Personalisation Scheme** =====
128
129 In some operations, the VTL assigns by default some standard names to some measures and/or attributes of the data structure of the result{{footnote}}For example, the check operator produces some new components in the result called by default bool_var, errorcode, errorlevel, imbalance. These names can be personalised if needed.{{/footnote}}. The VTL allows also to personalise the names to be assigned. The knowledge of the personalised names (if any) is essential for understanding the actual behaviour of the Transformation: this is achieved through the NamePersonalisationScheme. A NamePersonalisation specifies a personalised name that will be assigned in place of a VTL default name. The NamePersonalisationScheme is a container for zero or more NamePersonalisation.
130
131 ===== **VTL Mapping** =====
132
133 The mappings between SDMX and VTL can be relevant to the names of the artefacts and to the methods for converting the data structures from SDMX to VTL and vice-versa. These features are achieved through the VtlMappingScheme, which is a container for zero or more VtlMapping.
134
135 The VTL assumes that the operands are directly referenced through their actual names (unique identifiers). In the VTL transformations, rulesets, user defined operators, the SDMX artefacts are referenced through VTL aliases. The alias can be the complete URN of the artefact, an abbreviated URN, or another user-defined name, as described in the Section 6 of the SDMX Standards.{{footnote}}SDMX Technical Notes, chapter “Validation and Transformation Language”, section “References to SDMX artefacts from VTL statements”.{{/footnote}}
136
137 The VTLmapping defines the correspondence between the VTL alias and the structured identifier of the SDMX artefact, for each referenced SDMX artefact. This correspondence is needed for the following kinds of SDMX artefacts: Dataflows, Codelists and Concepts. Therefore, there are the following corresponding mapping subclasses: VtlDataflowMapping, VtlCodelistMapping and VtlConceptMapping.
138
139 As for the Dataflows, it is also possible to specify the method to convert the Data Structure of the Dataflow. This kind of conversion can happen in two directions, from SDMX to VTL when a SDMX Dataflow is accessed by a VTL Transformation (toVtlMappingMethod), or from VTL to SDMX when a SDMX derived Dataflow is calculated through VTL (fromVtlMappingMethod).{{footnote}}For a more thorough description of these conversions, see the Section 6 of the SDMX Standards (“SDMX Technical Notes”), chapter “Validation and Transformation Language”, section “Mapping between SDMX and VTL”.{{/footnote}}
140
141 The default mapping method from SDMX to VTL is called “Basic”. Three alternative mapping methods are possible, called “Pivot”, “Basic-A2M”, “Pivot-A2M” (“A2M” stands for “Attributes to Measures”, i.e. the SDMX DataAttributes become VTL measures).
142
143 The default mapping method from VTL to SDMX is also called “Basic”, and the two alternative mapping methods are called “Unpivot” and “M2A” (“M2A” stands for “Measures to Attributes”, i.e. some VTL measures become SDMX DataAttributes according to what is declared in the DSD).
144
145 In both the mapping directions, no specification is needed if the default mapping method (Basic) is used. When an alternative mapping method is applied for some Dataflow, this must be specified in toVtlMappingMethod or fromVtlMappingMethod.
146
147 ===== ToVtlSubspace, ToVtlSpaceKey, FromVtlSuperspace, FromVtlSpaceKey Although in general one SDMX Dataflow is mapped to one VTL dataset and vice-versa, it is also allowed to map distinct parts of a single SDMX Dataflow to distinct VTL data sets according to the rules and conventions described in the Section 6 of the SDMX Standards.{{footnote}}SDMX Technical Notes, chapter “Validation and Transformation Language”, section “Mapping dataflow subsets to distinct VTL data sets”.{{/footnote}} =====
148
149 In the direction from SDMX to VTL, this is achieved by fixing the values of some predefined Dimensions of the SDMX Data Structure: all the observations having such combination of values are mapped to one corresponding VTL dataset (the Dimensions having fixed values are not maintained in the Data Structure of the resulting VTL dataset). The ToVtlSubspace and ToVtlSpaceKey classes allow to define these Dimensions. When one SDMX Dataflow is mapped to just one VTL dataset these classes are not used.
150
151 Analogously, in the direction from VTL to SDMX, it is possible to map more calculated VTL datasets to distinct parts of a single SDMX Dataflow, as long as these VTL datasets have the same Data Structure. This can be done by providing, for each VTL dataset, distinct values for some additional SDMX Dimensions that are not part of the VTL data structure. The FromVtlSuperspace and FromVtlSpaceKey classes allow to define these dimensions. When one VTL dataset is mapped to just one SDMX Dataflow these classes are not used.
152
153 ===== **Custom Type Scheme** =====
154
155 As already said, a Transformation consists of a statement which assigns the outcome of the evaluation of a VTL expression to a result, i.e. an artefact of the VTL Information Model. which in the SDMX context can be a persistent or non-persistent Dataflow{{footnote}}Or a part of a Dataflow, as described in the previous paragraph.{{/footnote}}. Therefore, the VTL data type of the outcome of the VTL expression has to be converted into the SDMX data type of the resulting Dataflow. A default conversion table from VTL to SDMX data types is assumed{{footnote}}The default conversion table from VTL to SDMX is described in the the Section 6 of the SDMX Standards (“SDMX Technical Notes”), chapter “Validation and Transformation Language”, section “Mapping VTL basic scalar types to SDMX data types”.{{/footnote}}. The CustomTypeScheme allows to specify custom conversions that override the default conversion table. The CustomTypeScheme is a container for zero or more CustomType. A CustomType specifies the custom conversion from a VTL scalar type that will override the default conversion. The overriding SDMX data type is specified by means of the dataType and outputFormat attributes (the SDMX data type assumes the role of external representation in respect to VTL{{footnote}}About VTL internal and external representations, see also the VTL User Manual, section “Basic scalar types”, p.53.{{/footnote}}).
156
157 Moreover, the CustomType allows to customize the default format of VTL literals and the (possible) SDMX value to be produced when a VTL measure or attribute is NULL.
158
159 VTL expression can contain literals, i.e. specific values of a certain VTL data type written according to a certain format. For example, consider the following Transformation that extracts from the dataflow D1 the observations for which the “reference_date” belongs to the years 2018 and 2019:
160
161 Dr := D1 [ filter between (reference_date, 2018-01-01, 2019-12-31)]
162
163 In this expression, the two values 2018-01-01 and 2019-12-31 are literals of the VTL “date” scalar type expressed in the format YYYY-MM-DD.
164
165 The VTL literals are assumed to be written in the same SDMX format specified in the default conversion table mentioned above, for the conversion from VTL to SDMX data types. If a different format is used for a certain VTL scalar type, it must be specified in the vtlLiteralFormat attribute of the CustomType
166
167 Regarding the management of NULLs, in the conversions between SDMX and VTL, by default a missing value in SDMX in converted in VTL NULL and vice-versa, for any VTL scalar type. If a different value is needed, after the conversion from SDMX to VTL, proper VTL operators can be used for obtaining it. In the conversion from VTL to SDMX the desired value can be declared in the nullValue attribute (separately for each VTL basic scalar type).
168
169 ==== 15.3.2.2 Definitions ====
170
171 (% style="width:959.294px" %)
172 |**Class**|**Feature**|(% style="width:561px" %)**Description**
173 |Transformation Scheme|(((
174 Inherits from
175 ItemScheme
176 )))|(% style="width:561px" %)Contains the definitions of transformations meant to produce some derived data and be executed together
177 | |vtlVersion|(% style="width:561px" %)The version of the VTL language used for defining transformations
178 |Transformation|(((
179 Inherits from
180 //Item//
181 )))|(% style="width:561px" %)A VTL statement which assigns the outcome of an expression to a result.
182 | |result|(% style="width:561px" %)The left-hand side of the VTL statement, which identifies the result artefact.
183 | |isPersistent|(% style="width:561px" %)A boolean that indicates whether the result is permanently stored or not, depending on the VTL assignment operator.
184 | |expression|(% style="width:561px" %)The right-hand side of the VTL statement that is the expression to be evaluated, which includes the references to the operands of the Transformation.
185 |RulesetScheme|(((
186 Inherits from
187 //ItemScheme//
188 )))|(% style="width:561px" %)Container of rulesets.
189 | |vtlVersion|(% style="width:561px" %)The version of the VTL language used for defining the rulesets
190 |Ruleset|(((
191 Inherits from
192
193 //Item//
194 )))|(% style="width:561px" %)A persistent set of rules which can be invoked by means of appropriate VTL operators.
195 | |rulesetDefinition|(% style="width:561px" %)A VTL statement for the definition of a ruleset (according to the syntax of the VTL definition language)
196 | |rulesetType|(% style="width:561px" %)The VTL type of the ruleset (e.g., in VTL 2.0, datapoint or hierarchical)
197 | |rulesetScope|(% style="width:561px" %)The model artefact on which the ruleset is defined (e.g., in VTL 2.0, valuedomain or variable)
198 |UserDefinedOperator Scheme|(((
199 Inherits from
200 //ItemScheme//
201 )))|(% style="width:561px" %)Container of user defined operators
202 | |vtlVersion|(% style="width:561px" %)The version of the VTL language used for defining the user defined operators
203 |UserDefinedOperator|(((
204 Inherits from
205 //Item//
206 )))|(% style="width:561px" %)Custom VTL operator (not existing in the standard library) that extends the VTL standard library for specific purposes.
207 | |operatorDefinition|(% style="width:561px" %)A VTL statement for the definition of a new operator: it specifies the operator name, its parameters and their data types, the VTL expression that defines its behaviour.
208 |NamePersonalisation Scheme|(((
209 Inherits from
210 //ItemScheme//
211 )))|(% style="width:561px" %)Container of name personalisations.
212 | |vtlVersion|(% style="width:561px" %)The VTL version which the VTL default names to be personalised belong to.
213 |NamePersonalisation|(((
214 Inherits from
215
216 //Item//
217 )))|(% style="width:561px" %)Definition of personalised name to be used in place of a VTL default name.
218 | |vtlArtefact|(% style="width:561px" %)VTL model artefact to which the VTL default name to be personalised refers, e.g. variable, value domain.
219 | |vtlDefaultName|(% style="width:561px" %)The VTL default name to be personalised.
220 | |personalisedName|(% style="width:561px" %)The personalised name to be used in place of the VTL default name.
221 |VtlMappingScheme|(((
222 Inherits from
223
224 //ItemScheme//
225 )))|(% style="width:561px" %)Container of VTL mappings.
226 |VtlMapping|(((
227 Inherits from
228 //Item//
229
230 Sub classes are:
231
232 VtlDataflowMapping
233
234 VtlCodelistMapping
235
236 VtlConceptMapping
237 )))|(% style="width:561px" %)Single mapping between the reference to a SDMX artefact made from VTL transformations, rulesets, user defined operators and the corresponding SDMX structure identifier.
238 |VtlDataflowMapping|Inherits from //VtlMapping//|(% style="width:561px" %)Single mapping between the reference to a SDMX dataflow and the corresponding SDMX structure identifier
239 | |dataflowAlias|(% style="width:561px" %)Alias used in VTL to reference a SDMX dataflow (it can be the URN, the abbreviated URN or a user defined alias). The alias must be univocal: different SDMX artefacts cannot have the same VTL alias.
240 | |to
241 VtlMappingMethod|(% style="width:561px" %)Custom specification of the mapping method from SDMX to VTL data structures for the dataflow (overriding the default “basic” method).
242 | |from
243 VtlMappingMethod|(% style="width:561px" %)Custom specification of the mapping method from VTL to SDMX data structures for the dataflow (overriding the default “basic” method).
244 |VtlCodelistMapping|Inherits from //VtlMapping//|(% style="width:561px" %)Single mapping between the VTL reference to a SDMX codelist and the SDMX structure identifier of the codelist.
245 | |codelistAlias|(% style="width:561px" %)Name used in VTL to reference a SDMX codelist. The name/alias must be univocal: different SDMX artefacts cannot have the same VTL alias.
246 |VtlConceptMapping|Inherits from //VtlMapping//|(% style="width:561px" %)Single mapping between the VTL reference to a SDMX concept and the SDMX structure identifier of the concept.
247 | |conceptAlias|(% style="width:561px" %)Name used in VTL to reference a SDMX concept. The name/alias must be univocal: different SDMX artefacts cannot have the same VTL alias.
248 |ToVtlSubspace| |(% style="width:561px" %)Subspace of the dimensions of the SDMX dataflow used to identify the parts of the dataflow to be mapped to distinct VTL datasets
249 |ToVtlSpaceKey| |(% style="width:561px" %)A dimension of the SDMX dataflow that contributes to identify the parts of the dataflow to be mapped to distinct VTL datasets.
250 | |Key|(% style="width:561px" %)The identity of the dimension in the data structure definition of the dataflow that contributes to identify the parts of the dataflow to be mapped to distinct VTL datasets
251 |FromVtlSuperspace| |(% style="width:561px" %)Superspace is composed of the dimensions to be added to the data structure of the VTL result dataset in order to obtain the data structure of the derived SDMX dataflow (in case the latter is a superset of distinct VTL datasets calculated independently).
252 |FromVtlSpaceKey| |(% style="width:561px" %)A SDMX dimension to be added to the data structure of the VTL result dataset in order to obtain the data structure of the derived SDMX dataflow
253 | |Key|(% style="width:561px" %)The identity of the dimension to be added to the data structure of the VTL result dataset in order to obtain the data structure of the derived SDMX dataflow.
254 |CustomTypeScheme|(((
255 Inherits from
256 //ItemScheme//
257 )))|(% style="width:561px" %)Container of custom specifications for VTL basic scalar types.
258 | |vtlVersion|(% style="width:561px" %)The VTL version, which the VTL scalar types belong to.
259 |CustomType|(((
260 Inherits from
261 //Item//
262 )))|(% style="width:561px" %)Custom specification for a VTL basic scalar type.
263 | |vtlScalarType|(% style="width:561px" %)VTL scalar type for which the custom specifications are given.
264 | |outputFormat|(% style="width:561px" %)Custom specification of the VTL formatting mask needed to obtain to the desired representation, i.e. the desired SDMX format (e.g. YYYY-MMDD, see also the VTL formatting mask in the VTL Reference Manual and the SDMX Technical Notes). If not specified, the “Default output format” of the default conversion table from VTL to SDMX is used.{{footnote}}See “Mapping VTL basic scalar types to SDMX data types” in the SDMX Technical Notes, chapter “Validation and Transformation Language”.{{/footnote}}
265 | |datatype|(% style="width:561px" %)Custom specification of the external (SDMX) data type in which the VTL data type must be converted (e.g. the GregorianDay). If not specified, the “Default SDMX data type” of the default conversion table from VTL to SDMX is used.{{footnote}}See “Mapping VTL basic scalar types to SDMX data types” in the SDMX Technical Notes, chapter “Validation and Transformation Language”.{{/footnote}}
266 | |vtlLiteralFormat|(% style="width:561px" %)Custom specification of the format of the VTL literals belonging to the vtlScalarType used in the VTL program (e.g. YYYYMM-DD){{footnote}}See also the VTL formatting mask in the VTL Reference Manual and the SDMX Technical Notes.{{/footnote}}. If not specified, the “Default output format” of the default conversion table from VTL to SDMX is assumed{{footnote}}See “Mapping VTL basic scalar types to SDMX data types” in the SDMX Technical Notes, chapter “Validation and Transformation Language.{{/footnote}}.
267 | |nullValue|(% style="width:561px" %)Custom specification of the SDMX value to be produced for the VTL NULL values, with reference to the vtlScalarType specified above. If no value is specified, no value is produced.
268
269 ----
270
271 {{putFootnotes/}}