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.
Â
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.