Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rendering enum of multiple linked fields #7260

Open
Tasselhoff opened this issue May 12, 2021 · 1 comment
Open

Rendering enum of multiple linked fields #7260

Tasselhoff opened this issue May 12, 2021 · 1 comment

Comments

@Tasselhoff
Copy link

Tasselhoff commented May 12, 2021

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant