Re: [tosca] TOSCA key_schema must derive from string

["Nemeth, Denes (Nokia - HU/Budapest)" <denes.nemeth@nokia.com>]

Dear All

 

1. I think we should not introduce dynamic values for keys in Tosca maps, because in that case one could define a map that has the same key twice and from the static analysis of a template one would not be able to determine if the template is valid or not.
2. Technically it would be nice not to force the values of the map to be string, but other primitive values (specified in YAML [int, float, …] ) should be supported.
3. If we would opt for complex keys, than precise definition shall be available when two keys are considered to be the same.

 

Cheers Denes

 

From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org> on behalf of Tal Liron <tliron@redhat.com>
Date: Thursday, 2021. May 6. 23:08
To: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org>, adam souzis <adam@souzis.com>
Subject: [tosca] TOSCA key_schema must derive from string

Adam and all,

 

I looked up the issue and just want to clarify what we decided in the past:

 

1) A map key_schema must derive from string. It's a decision we made based on the same arguments you made, Adam, that non-string keys can be very problematic in many environments. We accepted that the main reason key_schema exists is to allow for constraints, not for supporting complex types.

 

2) That said, YAML itself does allow for complex map keys. That's a feature independent of TOSCA so there's not much point in us arguing about its merits. We've already decided that TOSCA aligns with YAML 1.2. So, this means that we could, potentially, allow for function calls in keys by using our map-and-single-key notation. That's entirely with what's possible with YAML.

 

Still, this is not so trivial -- the fact that the YAML spec allows for complex keys doesn't mean that all YAML parsers would do the right thing when decoding arbitrary YAML to native data structures. In fact, I suspect that most would choke on such an input. So, there's a programming challenge here if not a spec challenge. I can point to two specific solutions:

 

1) For Go's go-yaml parser I created yamlkeys.

2) For Python's ruamel.yaml parser I created ard.