Clarification needed on the absence of a Viral Propagation rule if a Viral attribute is defined

[javihern98]

Issue Description

The Reference Manual section Attribute propagation
(reference_manual/typical_behaviour.rst, lines 897–940) and the
define viral propagation construct
(reference_manual/vtl_dl_rulesets/viral_attributes.rst) describe how viral
Attributes are propagated and how the propagation algorithm is registered.
Neither states what happens when an Attribute is declared viral but
no viral propagation rule is defined for it — neither on its Represented
Variable nor on the Value Domain it uses.

Because virality (the Boolean flag) and the propagation algorithm are specified
separately, a "viral Attribute with no propagation rule" is currently a
syntactically valid but semantically under-defined state:

• viral_attributes.rst says the construct "registers the algorithm that must
  be applied whenever an operator propagates the value of a viral Attribute",
  and that when two or more values are combined the algorithm is applied pair by
  pair — but it does not say what applies when there is no such algorithm.
• The only NULL fallback documented (viral_attributes.rst, lines 49–52 and
  155–158) is the missing-else case inside an already-defined enumerated
  rule, not the "no rule at all" case.
• typical_behaviour.rst describes the default propagation behaviour assuming a
  rule/algorithm exists.

As a result the outcome is implementation-defined (propagate as-is? set to
NULL? reject?), which harms interoperability.

Proposed Solution

Specify that a viral Attribute without a viral propagation rule is a semantic
error, validated statically, and document it in the typical-behaviour section.

1. Reference Manual — typical_behaviour.rst, section "Attribute propagation"
   (new paragraph after the one ending at line 929):

   Once an Attribute is declared as viral, a viral propagation rule (see
   :doc:/reference_manual/vtl_dl_rulesets/viral_attributes) must be defined
   for it, either on its Represented Variable or on the Value Domain it uses.
   It is a semantic error for an Attribute to be viral when no viral
   propagation rule is defined for it.

2. Reference Manual — viral_attributes.rst, "Semantics" (consistency; next
   to the existing semantic-error statements at lines 17–19):

   It is a semantic error for an Attribute to be declared viral without a viral
   propagation rule defined for it (on its Represented Variable or on the Value
   Domain it uses).

This keeps the normative construct page and the typical-behaviour page aligned.

[linardian]

Dear @javihern98,

I understand the point, but I think we should not be too restrictive:

1. No problem for component operators (keep, drop, calc...) , since you can specify any rule for attributes
2. In an operation with two (or more) dataset having not overlapping viral attributes, there is no need to specify a propagation rule, since they will be carried in the result dataset as they are
3. The problem arises if the same viral attribute is common to two (or more) data sets: then a propagation rule must be defined.

Now the problem is: in the parsing phase, is it easy (or possible) to pick up the third case? If yes, I would enforce this check and an error should be raised. Do you agree?

[vpinna80]

Hi @javihern98, I agree with Angelo, from the user manual:

the default Attribute propagation rule behaves as follows:

• the non-viral Attributes are not kept in the result and their values are not considered;
• the viral Attributes of the operand are kept and are considered viral also in the result; in other words, if an operand has a viral Attribute V, the result will have V as viral Attribute too;
• ...
• Whenever in the application of a VTL operator two or more Data Points (belonging to the same or different Data Sets) are combined as for their Measures to give one output Data Point, the default propagation algorithm associated to the viral Attribute is applied, producing the Attribute value of the output Data Point. This happens for example for the unary Operators which aggregate Data Points and for Operators which combine the Data Points of more input Data Sets; in the latter case, the Attributes having the same names in such Data Sets are combined.

In other words, the last case is the only one requiring a "default propagation algorithm". Also to answer @linardian question, it is perfectly possible, during the semantic validation, to determine if a algorithm propagation rule is required or not; in fact I had already given a shot at this detection.

I also add that it would be easy to create "default propagation algorithms" for all the 8 basic scalar types if a more specific algorithm is not defined (i.e. take the later date, use string lexicographic order, etc.); I would prefer this over an error, imho failing on an attribute propagation is excessively bothersome for users.

[javihern98]

Ok, I added this proposal: #732 (comment)

We were able as well to detect the specific use cases where this is required with the semantic analysis. So it is feasible.

My first reaction over the 8 basic scalar types "default propagation algorithm" may be too wide and not be bound to any specific use case, I would be in favour of "default propagation algorithm" based on Concepts from SDMX or similar, but that must be considered within the SDMX standard