OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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

Â



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]