You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
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.
The text was updated successfully, but these errors were encountered:
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.
Content & configuration
Swagger/OpenAPI definition:
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
for the simple grouping above, or
for parent-child relationships. It allows simple parent-child relationships such as
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.
The text was updated successfully, but these errors were encountered: