On Wed, Mar 3, 2021 at 2:26 AM Bruun, Peter Michael (CMS RnD Orchestration) <
peter-michael.bruun@hpe.com > wrote: YAML parsers are not terribly happy about having anything but strings to the left of the : , so you will have to quote the name-_expression_: "{ concat: [ site-, { get_variable: [ SITE, name ] } ] }": I suggest you re-check your assumption here! Map keys in YAML do not have to be strings and indeed can be any valid YAML notation. As I said, it's an uncommon use. Indeed, in Go-lang it gave me enough trouble that it prompted me to create this library . Your example does raise a serious question about how the TOSCA functions distribute over list-type values. You are implying that if the value of SITE is [A, B, C], then your _expression_ would yield [Site-A, Site-B, Site-C], but it could just as well have yielded Site-[A, B, C] or Site-ABC . And what if you have another variable LOC with values [X, Y] and your concat-_expression_ uses both SITE and LOC. In your interpretation that would yield 5 nodes containing all 6 combinations like Site-A-Loc-X , Site-A-Loc-Y , Site-B-Loc-X , I think it could be quite deterministic, at least I think it should be. The "variables" keyword has a "list" sub-keyword, which will iterate (a for-loop) over all elements of the list. This particular list has 3 elements (of data type Site) so there should be no ambiguity. There are thus 3 iterations of the loop, and 3 different values for the variable SITE. The "get_variable" function can travel within the Site data type, but per iteration it would be the same SITE. P.S. I never have any luck with the oasis-list distribution. Can you please forward to the others for me? As far as I can tell your emails do come through!