TOSCA property/attribute functions and entity name and type uniqueness

[Calin Curescu <calin.curescu@ericsson.com>]

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:

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
1. I would propose to make the fully qualified name of a type unique across all types.
2. 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:
1. 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.
2. 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â
3. 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).
3. 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.
4. 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.
5. 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