RE: TOSCA examples from spec

[Chris Lauwers <lauwers@ubicity.com>]

Just because the YAML value is ânullâ doesnât mean this is invalid TOSCA in my opinion. Unfortunately, the TOSCA spec doesnât state how a TOSCA parser should interpret a null value. I interpret ânullâ to be equivalent to âthis is emptyâ or âthere is nothing hereâ.

 

We define this in terms of values. In TOSCA 2.0 there is a "nil" primitive type (it used to be called "null") which is the only type that can accept a null value, which is represented in YAML as null.

 

Also, I do think we define it for keywords. For example, a keyword type can be "string", "integer", "list of string", or "map of property assignments". For all of these I don't think null should be an acceptable value. A null value for a string is not equivalent to an empty string. A null value for an integer is not equivalent to zero. And a null value is not equivalent to an empty list or map. Thus, in my opinion, a TOSCA parser should emit an error if a null is used for any of these keywords. For an empty string you should put "". For zero, you should put 0. For an empty list you should put []. And for an empty map you should put {}. Thus there is no ambiguity about either types or values.

 

Yes, the key is whether there is ambiguity. As long as there is no ambiguity, we should err on the side of being permissive and make it as easy as possible for humans to author TOSCA files. For example, it is simpler in my opinion to write:

 

node_type:

relationship_types:

data_types:

capability_types:

interface_types:

artifact_types:

policy_types:

group_types:

 

than it is to write:

 

node_type: {}

relationship_types: {}

data_types: {}

capability_types: {}

interface_types: {}

artifact_types: {}

policy_types: {}

group_types: {}

 

Either way, there is no ambiguity: this template/profile does not define any types.

 

Thanks,

 

Chris