Re: [tosca] Inheritance of the "type" keyname: standpoint for TOSCA v1.2/v1.3?

[Tal Liron <tliron@redhat.com>]

On Wed, Aug 26, 2020 at 6:23 PM Chris Lauwers <lauwers@ubicity.com> wrote:

• For property definitions (and attribute definitions) the âtypeâ keyword is mandatory.
• For property (and attribute) refinements, the âtypeâ keyword is not mandatory. If the type is not specified in a refinement, then the type from the ârefinedâ property/attribute definition is assumed. If a refinement defines a âtypeâ, then that type must be âcompatibleâ with the type of the property/attribute definition that is refined.

I would combine these two points together and say that the "type" keyword is conditional on whether it is a refinement or not. By the way, the issue is not only whether you need to specify "type" or not but also what values are possible (must be the same or a derivation of the parent type).

Â

• For parameter definitions, the type is optional. The reason for this is that parameter definitions support a short-hand syntax that allows you to provide a value for the parameter. In most cases, that value will consist of an intrinsic function. If an intrinsic function is used, then the type of the value is the type of the property (or attribute or input) retrieved by that function (which the parser should be able to figure out). If the value is given inline in the service template (e.g. as a string or an integer) then the type can be derived from the YAML type for that value if the value has a âsimpleâ type. If a complex value is given inline, then we should specify a type so that the parser can validate that value.

This bothers me. I can understand the situation of *some* functions allowing a type to be discovered ad hoc, but I do not like the idea of potentially untyped values. One of TOSCA's best features is that it is strictly typed, and I worry about loopholes.

I think we should go back to actual use cases and try to look through the problems we are trying to solve here. Perhaps there is a better solution that would not require untyped parameters? Or, we can specify very carefully how function return values transfer types?