You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Why are requirements is list? So I can't override requirements via derived from mechanism. Can you explain why requirements is list? I think, that requirements should be dict and capability, node, relationship could be list.
The text was updated successfully, but these errors were encountered:
This is a good question and we've debated it quite a lot. I think it was decided in order to keep the requirement definitions in the same syntactical structure as the requirement assignments. However, grammatically they are quite different. In the node type it's a "sequenced list" meaning that a name can only appear once. So it's essentially equivalent to a map, and you can override it this way. But in a node template the same requirement name can appear more than once, because we are assigning individual requirements.
I am in favor of changing requirement definitions in node types to be a map.
As a rule of thumb, TOSCA uses lists whenever the order matters, which is definitely the case for requirements. A type designer may require that an orchestrator fulfill requirements in a specific order, e.g. when a node filter for requirement A uses a property value of a target node selected for requirement B. In that case, requirement B must be fulfilled before requirement A can be fulfilled. By organizing requirement definitions in a list, this ordering can be guaranteed.
Why are requirements is list? So I can't override requirements via derived from mechanism. Can you explain why requirements is list? I think, that requirements should be dict and capability, node, relationship could be list.
The text was updated successfully, but these errors were encountered: