Rationale

environments:
- name: port
  value: 8080
- name: theme
  value: light

advantage ⇒ easy to create a schema and process by machines

environments: 
  port: 8080
  theme: light

advantage ⇒ easier for using by humans

Additional references:

• https://github.com/kubernetes/kubernetes/blob/master/docs/devel/api-conventions.md#lists-of-named-subobjects-preferred-over-maps
• Document why we don't use maps in the API in api-conventions.md kubernetes/kubernetes#2004

Current goals/requirements:

• it should be easy to write DSL (solution 2), thus we support syntactic sugars and yaml vs just json
• it should be also easily processable - json with full DSL expansion (breed: x should be breed: reference: x)

To implement above we needed to have custom parsers and serialization but that also gives more control - data model is not "exposed" directly.

Proposal

If we use list approach we allow easier processing and we could do this:

• we keep current human friendly approach, thus custom parser and concise DSL - small change in additional resource "expansion"
• serialization to yaml/json should be done in list form