bellomarini
commented
7 years ago Just a clarification. Since the operators have positional and strongly-typed parameters, it is not necessary to have specific literal syntaxes to denote the various data types of the artefacts.
This means, that unlike basic types, whose literals must be distinguishable from their syntax (e.g. 2.0 is a double, 2 is an integer, "2" is a string), it is not the case for names referring to artefacts, as the context makes then unambiguous.
This assumption is also valid for the in-line definition of such artefacts, as we have explicit operators for the various artefacts, which are assumed to exclude name conflicts (also between persistent and temporary ones).
Description
There is no operator for referencing code lists too extensive for defining inline (e.g. NUTS 3) Add suitable operator(s) or modify defineValueDomain and defineValueDomainSubset.
Initially proposed solution
Allow referencing external code lists (like operator “get” references persistent datasets). Optionally allow transforming datasets into code lists.
Additional clarifications
In VTL-ML it should be possible either to use artefacts defined through the VTL-DL or to refer to external artefacts (e.g. coming from other standards). At the moment this feature is not homogeneously granted. For example, the VTL-ML allows to refer Value Domains/Code Lists, Sets, Code Item Relations defined through VTL-DL but does not allow to read Value Domains/Code List, Sets, Code Item Relations externally stored. On the contrary, VTL-ML allows to read the Data Set extensions of persistent Data Sets externally stored, but does not allow to define the Data Set extensions through VTL-DL. This general principle should be described in the User Manual (at the moment it is not). Moreover, in the Reference Manual, for each VTL IM artefact which needs to be referenced by VTL expressions, it should be granted that both the possibilities are allowed, i.e. either define the artefact through the VTL-DL or access the artefact externally stored. For achieving the former goal, all the needed artefacts should be definable through the VTL-DL (even the Data Set extensions for example), for the latter goal, there should exist operator/s which allows accessing all the needed artefacts when externally stored (for example it should be possible to access Value Domains/Code Lists, Sets, Code Item Relations externally stored); this/these operator/s should have a goal similar to the GET, which allows accessing Data Set extensions externally stored In VTL-ML it should be possible either to use persistent artefacts (meaning both the artefacts defined through the VTL-DL and externally stored, as described in the previous point) or to use non-persistent artefacts, e.g. artefacts directly written in-line, within the VTL-ML expressions. At the moment this feature is not homogeneously granted. For example, it is not possible to write in line the Data Points that form the extension of a Data Set. The general principle should be described in the User Manual (at the moment it is not). Moreover, in the Reference Manual, for each VTL IM artefact which needs to be used, it should be granted that VTL-ML allows to write it in-line (e.g. even the extension of a Data Set). If an artefact is written in-line it should be considered as non-persistent and therefore is not identified and cannot be reused. It should also be clarified that if an artefact is written in-line in a Ruleset (i.e. by using VTL-DL and not VTL-ML), although in itself it is not identified and non-persistent, nevertheless the Ruleset is identified and persistent and can be reused (therefore the artefact can be reused only within the Ruleset).
Proposed solution
Harmonized with the proposal for issue #36.
The proposed VTL type and module system (see the latest version of type-sys-update-YYYY-MM-DD.pdf attached in comments to issue #36) foresees modules as the main tool for organizing VTL code in a set of reusable units and for making different kinds of named objects, including in particular the IM artefacts, visible to VTL code:
The artefacts can be persistent and transient.
The persistent artefacts are maintained in a persistent store and are logically packaged (from the VTL point of view) in virtual modules. These modules are virtual because the artefacts are not defined in a textual VTL source code file, but come directly from the persistent store. Importing a virtual module make the named artefacts from the persistent store directly (and automatically) visible in the VTL program.
However, sometimes it is a good idea to generate a textual representation of the persistent artefacts from the persistent store for sharing between organizations. VTL implementations may include utilities that generate such VTL source code files for virtual modules containing the appropriate
definestatements for various artefacts from the persistent store. Such a VTL source file can be then sent to another organization and processed by a separate VTL utility that reads the source code of the virtual module and creates the artefacts in the target persistent store by interpreting thedefinestatements from the source code.The transient artefacts exist only for the duration of the VTL program execution. They are defined using the appropriate
definestatements either directly in the main VTL program source code, or in the source code of a user defined module imported (directly or indirectly) by the main VTL program. Not all artefacts can be defined in this way, only the value domains/sub-domains, data structures, rules, functions and procedures.When two or more virtual or user-defined modules imported by a VTL program define the same name, the definition from the later import wins, but the VTL compiler/runtime system should issue a warning listing the overlapping names and the modules from which they come.
There is no difference in using the persistent and the transient artefacts in VTL transformations. They are always referred to by name.