Hi,
While working on a converter from TOSCA XML to TOSCA YAML, we encountered following issues:
## Artifact Properties
- Line 1849 states that Artifact Types have properties.
- Section 3.6.7 (Lines 1188 to 1214) define an Artifact
An Artifact does not have a "Property Assignment"
We think that this should be added. That would be then consistent with "Node templates", which also have a property assignment "for assigning values to named properties (...) defined in their corresponding name types." (Lines 1329 and 1330).
## Types of Artifacts
The extended
notation
of an Artifact definition (Section 3.6.7.2.2, starting at Line 1200) requires the specification of a type (Line 1206). The short notation does not. This feels a bit inconsistent. Does one always need the type? Does one always know from the file extension which file type it is? Is ".zip" always a "ZIP" file? If yes, why does the extended
notation
require the type? Why is it not optional? -- I think, it should be always possible to convert a short
notation in an extended one. This is not the case here.
## Artifact Files
According to Line 1194, an Artifact can contain a single file only. In TOSCA XML 1.0, artifacts could reference multiple files. See lines 2610 to 2618.
In the general sense (and outlined in the example on page 18), it makes sense. However, what if I want to attach source code somehow? One could also think of an installer with a checksum file. I assume, I "just" have to ZIP the files to comply with the specification. Having a one-to-one relation of artifact and file seems to be an intuitive one.
## Outputs of operations
Section 3.6.15 (starting from Line 1492) defines Operations. An operation has inputs only. What about outputs? We think that it should be possible to specify the interface completely. Only specifying the inputs explicitly and relying on "get_operation_output" does not seem enough. How can one now which values to read using "get_operation_output"?
## Relationship templates
Section 3.8.4 (starting at Line 2224) defines Relationship templates. In case I have four node templates in my topology (n1, n2, n3, n4), where each par can be connected by the same relationship type. Let's say: n1 -> r12 -> n2, n3 -> r34 -> n4. How can I give r12 different properties than r34? The TOSCA XML spec used to have "source" and "target" for relationship templates. I don't find an equivalent in the YAML 1.2 PRD. "source" seems to be used for inheritance (line 2215).
Put in different words: How can I specify a topology graph using TOSCA YAML?
## Workflows
I cannot
find the terms "BPEL" and "BPMN" in the specification. It should be
allowed to use de-facto BPM languages also in TOSCA.
Side
note: The graph on Line 3654 reminds one of graphs defined in BPEL. We
once worked on a simple notation for BPEL at
http://bpelscript.org/. I
am not sure whether YAML is a proper serialization of workflows.
https://ballerinalang.org/ is another hot candidate for an orchestration language.
## Description field
In Section 5.9.14.1, Line 3411, the field "description" is used for both a capability and a requirement. Capability definitions have this field (1744), but requirement definitions do not (Line 1786)
## Operation implementation
Section 3.6.14 (starting on line 1453). Line 1457 defines "primary" of type "Artifact definition", but Line 1462 allows the short notation "primary artifact name". The table at line 1457 should also list that type, shouldn't it?
## Wrong reference: Interface assignments do not exist
Line 2132 (Section 3.8.2.2.3) shows "interface_assignments" linking to "3.6.16 Interface definition". Possibly the text at Line 2132 is just wrong.
## Impossible short notation
For the "Property Filter" definition, there is a short notation offered at line 1130 (Section 3.6.4.1.1). We think, this short notation is not possible, as a "constraint clause" is itself a key/value pair. So "example: greater: 2" is invalid YAML, isn't it?
## Missing tosca.entity.Root
- tosca.interfaces.Root derves from
tosca.entity.Root (line 3226)
- tosca.nodes.Root derives from tosca.entity.Root (line 3310)
However, the spec does not define
tosca.entity.Root
## Missing intro table at tosca.nodes.DBMS
All TOSCA types present a table with "shorthand_name", "type_qualified_name" and "type_uri". This is missing at Section 5.9.7 (should come after Line 3357)
## Inconsistent text
Section 3.7.4.1, Line 1849: The table has "mime_type" as not required, but the text reads "The required mime type". Same for "file_ext".
We are open for discussions.