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

[Chris Lauwers <lauwers@ubicity.com>]

Thanks Tal, comments in-line:

 

From: Tal Liron <tliron@redhat.com>
Sent: Wednesday, August 26, 2020 6:15 PM
To: Chris Lauwers <lauwers@ubicity.com>
Cc: Marton, Gabor (Nokia - HU/Budapest) <gabor.marton@nokia.com>; Calin Curescu <calin.curescu@ericsson.com>; tosca@lists.oasis-open.org; Nemeth, Denes (Nokia - HU/Budapest) <denes.nemeth@nokia.com>; Nguyenphu, Thinh (Nokia - US/Dallas) <thinh.nguyenphu@nokia.com>
Subject: Re: [tosca] Inheritance of the "type" keyname: standpoint for TOSCA v1.2/v1.3?

 

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).

 

Agreed. Thatâs what I meant by âcompatibleâ 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?

 

The point I was trying to make is that parameters are (almost?) never untyped, even when there is not type keyword specified. I would call them âimplicitlyâ typed (since the type can easily be derived). Yes, letâs work through some use cases to verify this. I believe if one has to specify both an (implicitly typed) value as well as an explicit type, this would be a violation of DRY.

 

Thanks,

 

Chris