For both the list and map types we currently have to provide an "entry_schema" (maps also have the optional "key_schema" keyword).
But I keep bumping into more and more use cases in which this is a burden. Kubernetes in particular in often accepts an "object" type (JSON nomenclature), which in TOSCA would mean a map with no predetermined entry schema. This "object" is likely validated at some point down the line by a runtime system. But there's no way to give it a clear schema in design-time (or perhaps the devs were lazy!).
There is no elegant way to describe this kind of data in TOSCA. On hack could be to use: "entry_schema: tosca.datatypes.json", and provide that object as a string. So, TOSCA would provide some level of validation, but obviously it is quite ugly.
This does bleed into another discussion we had about the necessity to have some kind of "any" type in TOSCA, for cases when not even a map, specifically, is required. Which then leads to an interesting possibility to add a type constraint:
properties:
 config:
ÂÂÂ type: any
ÂÂÂ constraints:
ÂÂÂ - valid_types: [ string, map, list ]
Or, possibly, could the "type" keyword allow for a list? E.g.:
properties:
 config:
ÂÂÂ type: [ string, map, list ]
I have not thought deeply yet about the consequences. :)