OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

Hi,
 
Since we talked about entity names a previous discussion, I also want to raise the following problems of property/attribute functions and name uniqueness:

In requirements in several places we can have either Capability types or Node types, so there is a problem if we have a node type and a capability type with the
same name
I would propose to make the fully qualified name of a type unique across all types.

The get_property and get_attribute may refer into the capability and requirements hierarchy. But there is no way to distinguish if a name in the path is a requirement
or a capability or a property/attribute. There are 3 ways to solve this:
requirements and capabilities and properties/attributes names must be unique within a node definition. This could be a problem if I derive a node and want to add
a new capability with a certain name but I cannot since it s occupied by a previously defined property. We change the get_property and get_attribute function to specify the entity type before the name. i.e. introduce the PROPERTY or CAPABILITY or REQUIREMENT keyword
in the path We can use alternatively the
fully qualified capability type name for a capability instead the capability name . I think this to be the best option. I mean if I have a requirement where I specify the capability type to match, I might not even know the capability name in the
matched node. So this referencing would be much more useful. This would of course mean that we should not be able to define two capabilities of the same type in a certain node type, which is ok (capabilities should be qualitative not quantitative).
The get_property resolution. We need to decide if we want the matching phase mix with the property assignment phase. This is unavoidable if we allow get_property
to reach in the requirements nodes. This may get especially complex since the matching itself may depend on property values that need to be resolved before the matching can be resolved. It would be good to be able to get also to the properties and attributes of the relationship in a requirement not just of the target node. It is not specified what the get_property will do in case we have a requirement with a multiple occurrences. I propose in this case to return a list containing all
such properties in all instances. But we should revisit this once e defined how to handle multiplicity.
 
I think we need to revisit these topics once we are done with the more important stuff, but I wanted to gather my thoughts on this topic.
 
BR,
/Calin

On Fri, Sep 13, 2019 at 7:07 AM Calin Curescu < calin.curescu@ericsson.com > wrote: In requirements in several places we can have either Capability types or Node types, so there is a problem if we have a node type and a capability type with the same name I would propose to make the fully qualified name of a type unique across all types. The get_property and get_attribute may refer into the capability and requirements hierarchy. But there is no way to distinguish if a name in the path is a requirement or a capability or a property/attribute. There are 3 ways to solve this: requirements and capabilities and properties/attributes names must be unique within a node definition. This could be a problem if I derive a node and want to add a new capability with a certain name but I cannot since it s occupied by a previously defined property. This is a very serious downside -- changes to the underlying types (e.g., if the capability type is imported) can introduce conflicts and force you to change names of properties, which can have cascading effects on orchestrations. In fact it might not even be possible to change property names if the property names are enforced by orchestration. So I think it's crucial to have each of these things exist within their own namespace. We change the get_property and get_attribute function to specify the entity type before the name. i.e. introduce the PROPERTY or CAPABILITY or REQUIREMENT keyword in the path Seems entirely fine to me: { get_property: myNodeTemplateName, CAPABILITY, myCapabilityName, propertyInCapabilityName } We can use alternatively the fully qualified capability type name for a capability instead the capability name . I think this to be the best option. I mean if I have a requirement where I specify the capability type to match, I might not even know the capability name in the matched node. So this referencing would be much more useful. This would of course mean that we should not be able to define two capabilities of the same type in a certain node type, which is ok (capabilities should be qualitative not quantitative). It is very useful to have two capabilities of the same type! The capability definition is a kind of instantiation of the type, and each definition could refer to a different actual capability. Thing of something simple like a NetworkPort. You can have many ports on a node type, each with its own use. It is not specified what the get_property will do in case we have a requirement with a multiple occurrences. I propose in this case to return a list containing all such properties in all instances. But we should revisit this once e defined how to handle multiplicity. This would be very problematic because of ambivalently typed results. What isfthe property type is a list? So you would get a list back always and you wouldn't know if you should parse that list for multiple results, or if that result is singular and is a of the list type.

Hi Calin
 

1)      
In requirements in several places we can have either Capability types or Node types, so there is a problem if we have a node type and a capability type with the same name
 
I m not sure I understand the problem. Don t we use node and capability keywords to distinguish between the two? I m not aware of scenarios where the problem you describe exists.
 
Thanks,
 
Chris