I thought of another potential concern due to this often-overlooked YAML feature.
TOSCA parsers written in un-typed languages (Python, Ruby) may very well forget to check that names of types, properties, operations, etc., are strings. Since these are provided as YAML keys in the TOSCA syntax, it may be just assumed that the YAML parser did the right thing and made sure that they are strings. But it might not be so. For example, before I implemented the check this would be allowed in Puccini (after I added support for complex key maps):
node_types:
 {complex: name}:
  derived_from: Root
But this legal YAML should be illegal in TOSCA, because the "type" keyword in a node template (and other places, such as "node" in requirements) is defined as a string. It would make sense, then, to generalize and specify in the spec that all entity names should be strings. (This also means no integers, floats, etc.) It makes sense that a name would be a string and this would clarify consumption of TOSCA by orchestrators and other tools. E.g., in an instance model a database column for a name in could be confidently defined as type "text".
This should also apply to property/parameter/input names. E.g.:
node_types:
 MyNode:
  properties:
   {complex: name}:
    type: string
While it could be argued that property names are arbitrary, this could lead to unnecessary complexity in other parts of the language. E.g. the "get_property" function would need to support complex property names. And again, tools may want to store these names predictably. For consistency, then, we could require all such names (to be clear, they are not entity names) to also be strings.
To phrase it conversely, the only place in TOSCA where complex YAML keys should be allowed is in the schemas of complex data types, where TOSCA provides an explicit feature (key_schema) to specify it.
Implementators take note! We should be very careful to avoid automatic translation of non-strings to strings in such cases (some dynamic languages do this automatically for you) because each programming language would do it differently, leading to incompatibilities between TOSCA implementations. Even a number (integer, float) could become a different string in different programming languages. So, this should be illegal in TOSCA (though it is legal YAML):
node_types:
 6:
  derived_from: Root
But this should be fine TOSCA:
node_types:
 '6':
  derived_from: Root
The ruamel parser I use flags duplicate keys as an error. I assume that is the desired behavior, but youâre right that we should state that explicitly in the
spec.
Â
Chris
Â
From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
On Behalf Of Tal Liron
Sent: Wednesday, September 11, 2019 2:55 PM
To: tosca@lists.oasis-open.org
Subject: Re: [tosca] key_schema in TOSCA 1.3?
Â
Final chapter in the drama: I have found a solution in Go for complex keys in YAML. It's very complex -- basically I had to redo some of the decoding that the YAML library does, but it does work with the public APIs and does emit an error
if duplicate complex keys are used in a YAML map.
One thing to note -- most YAML parsers are "non-strict" in that they allow for maps to have repeating keys, in which case later keys tend to override previous ones. Except ... in the case of a YAML merge (<<) in which the spec specifically
says that keys do not get overridden.
Does TOSCA specify if duplicate keys are allowed? It's probably a good idea to do so in order to maintain compatibility between TOSCA parsers.