[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?
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>
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> Thanks, Tal. Does this also mean that, up to TOSCA v1.3, the following sentence:
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>
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:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]