TC approves closing this issue without further action on 9/6 (see https://www.oasis-open.org/apps/org/workgroup/tosca/download.php/46841/TOSCA%20TC%20Minutes%202012-09-06.docx).

As you know, specifications in standards are about improving interoperability. That will often involve constraining choice, rather than expanding it or listing it, as long as you can find consensus in the TC. Will you be proposing specific text changes to the spec or text/images for a primer, e.g., BPMN as a SHOULD or a MUST?

If this discussion is also evolving towards a "base set" of operations, properties, and maybe a small number of nodes, should this discussion not be informed by one or more use cases? See TOSCA-8, which suggests but does not yet provide some use cases. I have also uploaded a use case template, which folks could use to get things rolling.

I am absolutely fine with specifying in TOSCA that BPMN 2.0 is the default language for defining plans.

Wrt "artifacts", we need be more specific.

We define "implementation artifacts" as the "executables" realizing operations. The spec lists potential types of operations, i.e. WSDL port type operations, REST interfaces, and scripts. WSDL port types are often implemented as servlets but also as EJBs (in addition to corresponding Windows components). Thus, we should add EARs to Derek's list. REST interfaces are often realized as servlets, i.e. from a Java perspective JAR files or WAR files should be fine. The list of script languages is fine with me, but I need to delegate the list of scripts to others (this is not my skill area).

We define "deployment artifacts" as the "executables" realizing node types/templates. When a node type/template represents infrastructure, i.e. OS or middleware (DBMS, App Server,...) assuming images is fine. The list of VM image formats to be supported needs to be discussed. Also, we need to include AMIs (or references to them) because of their frequent use. But if we move from infrastructure up towards the implementation, we need to support artifacts that represent service- and process-oriented applications. Thus, the artifact types include WSDL files, BPEL- and BPMN files, EAR/JAR files (implementing the WSDL port types) and so on.

Summary: The list is an excellent base, but we should consider to extend it in order to reflect applications that are often (expected to be) run in a cloud environment.

Can we address Frank's Ad 2 and select the process model and smallest set of implementation artifacts that MUST be supported by a compliant implementation so we can generate real TOSCA compliant plans? This will support additional concrete questions.

Here is a proposal to keep it representative but simple:

Process Model:
BPMN

Implementation Artifacts:
WAR (simpler than EAR)
VMImage (OVF, RAW (versus all possible))
Scripts (SH, PowerScript, Perl, Python)

Does this discussion need text in the spec or in a primer? If so, please provide text for review. Otherwise, we should close this issue.