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

Hi Gabor, Tal,

Both in TOSCA v1.2 and v1.3 we have the following statement:

The TOSCA metamodel includes complex types (e.g., Node Types, Relationship Types, Capability Types, Data Types, etc.) each of which include their own list of reserved keynames that are sometimes marked as required. These types may be used to derive other types. These derived types (e.g., child types) do not have to provide required keynames as long as they have been specified in the type they have been derived from (i.e., their parent type).

Now, it does not go into the detail, that this applies also to the entities definitions inside (i.e. propserties,attributes, interfaces, etc.) but it is âassumedâ 😊.

In TOSCA v1.3 we realized that we should be more explicit, so we have for the first time a section on ârefinementsâ that explicitly states what you ask:

3.6.10.6 Refining Property Definitions

TOSCA allows derived types to refine properties defined in base types. A property definition in a derived type is considered a refinement when a property with the same name is already defined in one of the base types for that type.

Property definition refinements use parameter definition grammar rather than property definition grammar. Specifically, this means the following:

Â The type keyname is optional. If no type is specified, the property refinement reuses the type of the property it refines. If a type is specified, the type must be the same as the type of the refined property or it must derive from the type of the refined property.

Â Property definition refinements support the value keyname that specifies a fixed type-compatible value to assign to the property. These value assignments are considered final, meaning that it is not valid to change the property value later (e.g. using further refinements).

Regarding the default type as string that is valid only for parameters as you mention.

BR/Calin

From: <tosca@lists.oasis-open.org> on behalf of "Marton, Gabor (Nokia - HU/Budapest)" <gabor.marton@nokia.com>
Date: Tuesday, 25 August 2020 at 09:53
To: Tal Liron <tliron@redhat.com>
Cc: "tosca@lists.oasis-open.org" <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?

Thanks, Tal.

Does this also mean that, up to TOSCA v1.3, the following sentence:

âThe âstringâ type is the default type when not specified on a parameter or property declarationâ (3.3 Parameter and property types).

in practice, only refers to parameter declarations/definitions (where the type keyname is not mandatory) but not to property declarations/definitions?

GÃbor

From: Tal Liron <tliron@redhat.com>
Sent: Monday, August 24, 2020 4:06 PM
To: Marton, Gabor (Nokia - HU/Budapest) <gabor.marton@nokia.com>
Cc: 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?

Because up to TOSCA 1.3 the "type" keyword was listed as mandatory, I would assume that all implementations would require you to explicitly specify it, even if it was the same as in the parent. Those that do not I would consider non-compliant.

You are correct that it can be easily derived, which is what we want to fix in TOSCA 2.0. Generally we understand that the "mandatory" column (used to be confusingly called "required") is often not just "yes" or "no" but that in many cases it is conditional on inheritance or association to other keywords.

On Mon, Aug 24, 2020 at 6:56 AM Marton, Gabor (Nokia - HU/Budapest) <gabor.marton@nokia.com> wrote:

Dear TOSCA Experts,

in TOSCA v1.2 and v1.3, is the below provider.nodes.Example node type definition valid i.e. does it inherit the âtypeâ keynames from its parent?

node_types:

provider.nodes.Base:

    derived_from: tosca.datatypes.Root

    properties:

      property_1:

        type: string

      property_2:

        type: integer

provider.nodes.Example:

    derived_from: provider.nodes.Base

    properties:

      property_1:

        constraints:

          - valid_values: [ value_1, value_2 ]

      property_2:

        constraints:

          - in_range: [ 1, 10 ]

The related parts of TOSCA v1.2/v1.3 are ambiguous:

The âtypeâ keyname is a mandatory part of a property definition (3.6.10 Property definition).
âThe âstringâ type is the default type when not specified on a parameter or property declarationâ (3.3 Parameter and property types).
Furthermore, I can see no example in the specs that would serve as a precedent for the above example. On the other hand, I guess that inheritance in TOSCA has been meant to work like this.

I understand that in the TOSCA v2.0 draft, this aspect is covered in line with the above assumption (âIf not refined, usually a keyname/entity definition, is inherited unchanged from the parent type, unless explicitly specified in the rules that it is ânot inheritedââ; 4.2.5.1 General derivation and refinement rules).

I am still asking this question related to TOSCA v1.2/v1.3, because implementations differ in this respect, resulting in interoperability issues, turning out too late.

Greetings,

GÃbor

tosca message