If the lower bound in the occurrences keyword is greater than zero, then
we call the requirement a âmandatory requirementâ.
I think we also agreed that unassigned mandatory requirements can be automatically assigned by the processor, just as a quality-of-life thing. It would be equal to an empty assignment, meaning that if the relationship type has required properties then this would result in an error, implying that the designer must manually assign them.
Â
A topology
representation is invalid if it contains node representations with
mandatory requirements that are not fulfilled.
It's unclear to me why you used the word "mandatory" here. Shouldn't all assigned requirements be fulfilled?
Â
If a node template has a mandatory requirement that is not fulfilled, we call that requirement a âdangling requirementâ.
It's even more unclear to me why you used the word "mandatory" here. You would consider any assigned requirement that is unfulfilled to be "dangling", no? Even if occurrences were [ 0, UNBOUNDED ] (meaning non-mandatory in your definition).
Moreover, as you know, I do not think dangling (unfulfilled) requirements should be allowed anywhere in TOSCA. "Dangling" in my view = error.
There is one place where we very unfortunately must allow it: substitution mapping. A mapped requirement must be dangling for the scheme to work. Yet another reason why I dislike substitution mapping grammar.
Â
-
I also question whether it should be legal to use the âoccurrencesâ keyword inside requirement assignments. Clearly, for actual requirement assignments (i.e., the scenario where we assign a target node to a requirement), the occurrences keyword does not make
sense and should not be used. For the scenario where we specify a dangling requirement inside a node template, what happens if we specify the dangling requirement multiple times (i.e., define multiple requirements with the same name) inside the same node template,
and in addition, we specify multiple occurrences for each of these requirement instances? Is this allowed?
I (or someone else?) raised this about a year ago and I thought we agreed that it is illogical to allow "occurrences" in requirement assignments, because we understand it (in the requirement definition) to mean exactly how many assignments are necessary (min) and allowed (max).
Now let's also please talk about how "occurrences" in capabilities also doesn't make sense (or if it does, it means something entirely different than it does in requirements and if so should not be called that).
On that note I suggest renaming "occurrences" in requirements to "assignments". As it stands it's hard to understand what the keyword means by its name.