Re: TOSCA key_schema must derive from string

[adam souzis <adam@souzis.com>]

Thank you, Tal for following up on this. It's really good toÂhear that TOSCA made the wise decision to only allow strings for the key_schema. I don't think that decision should be revisited.Â

my $.02...

Adam

On Thu, May 6, 2021 at 2:08 PM Tal Liron <tliron@redhat.com> wrote:

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.