It sounds like we all agree that fulfilling dangling requirements will always result in complete and valid node representation graphs (assuming suitable target nodes can be found) which in the end is all that matters.
Well, I also think that the design graph matters. A lot.
Â
Tal is correct that target nodes used for dangling requirements will not have a corresponding node template in the service design, but I honestly donât understand why this is a problem. Is there anything that canât be validated, or that
introduces ambiguity, or that increases the likelihood of errors? Or is this strictly an issue of esthetics and personal preference?
Without a node template, there's nothing the designer can do with that target node. The designer cannot relate that node to something else. The designer cannot relate other nodes to the same target. The designer cannot call "get_attribute" or "get_property" on it because it has no name (unless they are specifically trying to refer to it in the context of relationship values, which is the only place the TARGET keyword works).
Moreover, there is no way to express this using standard (network) graphs. Think of the Cloudnet presentation from last week: in order to visualize such a "dangling" edge there would have to be a line coming out of one node pointing to ... nothing. Or, perhaps visually, it could be a box with a dotted line around it and a "n/a" for its name. So this might be the "aesthetic" awkwardness.
But these graphs are more than aesthetics. I can see someone creating a TOSCA processor that uses a graph database to store all the topology templates. This can be very powerful for querying across a huge set of topologies, for example to find usage statistics, suggest optimizations, and even apply policies -- even if we enriched TOSCA's policy language, it would still only apply to one topology template, but a database of all of them can do more powerful things. A graph database does not have the concept of a line pointing nowhere. A broken graph here is not just a visual problem, it's a hurdle to a valid implementation of TOSCA.