Profile

Dear TOSCA Experts, the specification---TOSCA v1.3 as well as the 2.0 draft---seems to be self-contradicting in the extended notation in policy trigger activity definitions. Taking call_operation as an example: In section 3.6.23.3 Call operation activity definition, the keynames are, all in the same ...

HI Tal, I would like to comment on DÃnes first point, regarding the ambiguity of the property assignment definition in the specs. Maybe it could be handled in the specs in the following way (on top of the TOSCA-v2.0 draft ): 4.4.8.2.1 Short notation: [remaining the same] 4.4.8.2.2 ...

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

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

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