OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

tosca-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: TOSCA examples from spec

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.

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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]