Hi,
Both tosca.nodes.Compute and tosca.capabilities.Compute have the shorthand name Compute. And this is in the existing normative type definition set.
Now, section 5.2 TOSCA normative type names says in one of the rules that:
c. TOSCA type designers SHOULD NOT create new types with names that would collide with any TOSCA normative type Shorthand Name.
But it is not specified if across types or not. Now, maybe people thought that this is not a problem since in the derivation we are supposed to know that nodes come from nodes and capabilities from capabilities. But
in the requirements definition I can accept both, so what does the orchestrator do in that case?
Moreover, I think there are general problem with the shorthand names:
They are arbitrary, sometimes they are the last name in FQ name, sometimes it s the last two names Not symmetrical, why do we have a shorthand name in the TOSCA namespace but not in the custom namespaces.
BR,
/Calin
From: Chris Lauwers <
lauwers@ubicity.com>
Date: Monday, 16 September 2019 at 23:45
To: Calin Curescu <
calin.curescu@ericsson.com>, Tal Liron <
tliron@redhat.com>
Cc: "tosca@lists.oasis-open.org" <
tosca@lists.oasis-open.org>
Subject: RE: TOSCA property/attribute functions and entity name and type uniqueness
Hi Calin
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