Re: TOSCA property/attribute functions and entity name and type uniqueness

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

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

 

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