Rendering enum of multiple linked fields

[Tasselhoff]

Content & configuration

Swagger/OpenAPI definition:

          coding:
            type: array
            items:
              type: object
              properties:
                system:
                  type: string
                  default: http://terminology.hl7.org/CodeSystem/v3-RoleCode
                code:
                  type: string
                display:
                  type: string               
              enum:
                - {code: DX,display: Diagnostics or therapeutics unit} 
                - {code: CVDX,display: Cardiovascular diagnostics or therapeutics unit} 

The above is perfectly fine for OpenAPI Specification (in that it doesn't give an error), but there is no rendering of the code and display pairs

It would be useful to be able to document the link between separate field values that need to be consistent.

It would also be interesting to incorporate parent-child relationships between enum values (I'm not sure if this already exists or not). So, for example there could be type-code, type-display and type-definition values that need to be consistent as above, but also subtype-code, subtype-display and subtype-definition that depend on a given value of type-code (or its set of consistent values).

This could be made explicit by something like

enum:
  enumgroup: {code, display}
  - {code: DX,display: Diagnostics or therapeutics unit}

for the simple grouping above, or

enum:
  enumgroup: {type-code, type-display, type-definition, {subtype-code, subtype-display, subtype-definition}}

for parent-child relationships. It allows simple parent-child relationships such as

enum:
  enumgroup: {type, {subtype}}

and, for example grandparent, parent, child relationships too by further nesting.

If, for example, type-code was the only required field at the top level, it could be used as the "key" for the child set of values (allowing no values for the non-required top level fields, for example).

Edit: I'm not much of a fan of using nested object representation for parent-child relationships when the implementation may not want them as nested objects. Feel free to think of some other way of representing it if breaks norms. The problem here is that we are straddling the rendering and the implementation of the actual OpenAPI Specification too.

[Tasselhoff]

Ignore the nesting for now, as we could just repeat the parent value for each of the relevant child values. What is important is to be able to enum several, say, string values together within an object. I have cases where there are tens of thousands of "code", "display" and "definition" fields whose values need to be linked to each other but I'm currently using a separate enum for each of the fields which doesn't take into account the fact that for a given code you have to choose the relevant display and definition values.