RE: TOSCA examples from spec

[Chris Lauwers <lauwers@ubicity.com>]

 

On Fri, Jan 28, 2022 at 11:35 AM Chris Lauwers <lauwers@ubicity.com> wrote:

Yes, my apologies. In the Ubicity parser, I run in a more permissive mode by default that doesnât enforce string values in metadata. I find this overly restrictive, and I donât see any benefit to limiting metadata to strings (nor do I see any downside to allowing arbitrary values since metadata are purely for informational purposes and not intended to be used for anything). This is a topic Iâd like to revisit before we release v2.0.

 

Yes, please. I've made a similar proposal in the past -- that we allow any arbitrary YAML 1.2 data in "metadata". Let's please add this to the TODO spreadsheet so we don't forget.

Great. Hopefully no one disagrees so we can just include this in the spec.

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.

 

That's not to say that Ubicity's interpretation is unreasonable, but I think we all agree that this should be consistent across implementations. Let's then also please add a decision about this to the TODO spreadsheet.

Yes, we should distinguish between values that need to comply with TOSCA types vs. syntax elements in the language. I completely agree that for âvaluesâ there is a difference between âan empty mapâ vs. ânullâ and the spec needs to spell out exactly how YAML values map to TOSCA values. However, I was talking more specifically about syntax elements in the language. For example. I donât believe there should be any difference between the two following âemptyâ service templates:

 

tosca_definitions_version: tosca_simple_yaml_1_3

topology_template:

 

and

 

tosca_definitions_version: tosca_simple_yaml_1_3

topology_template: {}

 

I think both should be valid. As a general rule, we should make the TOSCA syntax as permissive as possible without sacrificing correctness.

 

Chris