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

[Tal Liron <tliron@redhat.com>]

Sorry to belabor this, but TOSCA 1.3 is inconsistent. In the attribute definition (3.6.12.2) "type" is required. In the property definition (3.6.10.2) "type" is required. It's only in parameter definition (3.6.14.1) that it is not required. Section 3.5.1 is in some ways more confusing than clarifying and is exactly what led us to realize that we need to talk about "refining" in 1.3. The situation is the same in TOSCA 1.2 (different section numbers).

So actually for TOSCA 1.3 the only clarification we got is the addition of 3.6.10.6, which unfortunately is only for properties and not for attributes and parameters. Again, we can make assumptions, but it's these kinds of assumptions that lead to lack of portability.

The end result is that I would not blame TOSCA implementations up to 1.3 for doing whatever they want with the "type" keyword, as there is conflicting information. I'm sure this is going to be much clearer in TOSCA 2.0 as Calin has done great work on "refinement" generally.

And by the way, Puccini already does the right thing here. I forgot that I fixed this a long time ago. :)

On Tue, Aug 25, 2020 at 11:02 AM Tal Liron <tliron@redhat.com> wrote:

Thanks for correcting me, Calin! This was really hidden away in 1.3. :) It is unfortunately not mentioned in the Parameter Definition section (3.6.14), although indeed the "required" column for "type" is "no".

I will fix Puccini to conform to this for 1.3 (and stay "required" for <=1.2).

On Tue, Aug 25, 2020 at 5:23 AM Marton, Gabor (Nokia - HU/Budapest) <gabor.marton@nokia.com> wrote:

Thanks, Calin.

Â

I overlooked these sections. (I can now recall that we had a related discussion cca. two years ago, after which the refinement-related section was introduced in TOSCA v1.3, but somehow it slipped from my memory.)

Â

Greetings,

Â

GÃbor

Â

From: Calin Curescu <calin.curescu@ericsson.com>
Sent: Tuesday, August 25, 2020 11:09 AM
To: Marton, Gabor (Nokia - HU/Budapest) <gabor.marton@nokia.com>; Tal Liron <tliron@redhat.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?

Â

Hi Gabor, Tal,

Â

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

3.5.1 Required Keynames

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

Â