Hi all, I will do my best to offer clear comments! I have decided to stick to the first slide only, in order to avoid making this email too long.
The dotted line assumes that the "service instance model" is in the scope of the TOSCA processor, and that in turn is the input for the orchestrator. This introduces two problems:
1) Orchestrators may very well come with their own way to manage deployable services. Flexible model-driven orchestrators may be able to accommodate TOSCA models directly, or at least a subset of supportabe features. In such cases the TOSCA processor might not be an external component but rather integrated into the orchestrator to work directly with its native model system. The concept of "service instance model" is still grammatically relevant to TOSCA, but the dotted line in such cases would leave the "service instance model" out, as it would actually be part of the orchestrator. Another way to look at this is that there is slippage between "grammatical architecture" and "functional architecture", which is the title of this slide deck.
2) As Thinh pointed out, this also introduces a standards compliance challenge, which will have cascading effects for other standards that refer to TOSCA. I think it's most responsible for us as a standards body to allow for TOSCA processors that do not introduce an intermediary state, which indeed has been the norm for many existing implementations. Again, I absolutely agree that the concept is very important to clarify the functionality of intrinsic functions, relationships, substitution, and other features, but we need to be careful not to assume how such functionality would be implemented. E.g. Puccini implements intrinsic functions against the intermediary state, but it's easy to imagine other implementations that rely on metadata stored in controllers or the cloud platform itself.
And, as politely noted in the slides, I am uncomfortable with calling it an "instance model" and indeed boxing up "instantiation" as a processing component. This is related to the problems mentioned above: for implementations that do not use an intermediary state there would be no such "instantiation", at least not as diagrammed here. "Instantiation" would be part and parcel of the deployment process itself. Using my example above: it's only when resources are deployed that you can inject metadata. If anything, such "instantiation" as we are referring to here might even happen after the resources are created.
Furthermore, it might not even be a phase per se. In the two implementations of a TOSCA processor that I've worked on, very different approaches were used. In Puccini I have indeed implemented this as a phase, the result being "normalized" data structures. These "normal" structures are "flattened" versions of the template entities (node templates, policies, groups) with the entire type hierarchy and inheritance having been validated and resolved, e.g. all properties are listed, default values assigned if necessary, etc. Importantly, intrinsic functions are not called in this phase, but rather normalized (and validated) call stubs are inserted instead. In the ARIA project we used a very different approach: everything was handled by lazy evaluation, e.g. when you tried to read the value of a node template's property it would reach through the various hierarchies, validate/inherit on-the-go, and also call intrinsic functions. There was thus no specific normalization phase. Having worked with both approaches, my opinion is that a separate phase is preferrable. However, this is an implementation detail that we should not enforce.
Thinking through these problems, my current feeling is that it may be best to abandon trying to standardize the functional architecture and instead focus on the grammatical architecture. My proposal is that in the text of the spec we refer, where necessary, to the "normalized representations" of node templates, without making assumptions for how these are generated or whether they are stored in an intermediary state, the platform itself, or anywhere else. This is actually a non-trivial and powerful requirement, because it assumes that TOSCA processors would need to have access to such normalized representations. Until TOSCA 2.0 this could not be assumed.
The concept of a "normalized representation" goes a long way to clarifying how various intrinsic functions work, but most importantly in my view it explains TOSCA relationships. The satisfaction of requirements, and thus the construction of the graph, happens between the normalized representations. This will allow us to think more clearly about what "occurrences" could mean for capabilities and requirements.
I can already guess that there would be objections to my proposal, because some of you would very much like to require that intermediary state to exist in order to enable controversial features such as "dangling requirements" and mulitplicity of template "instances", which would require a clear notion of an instantiation phase. And indeed this is one reason why I object to such features.