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
{{ message }}
Repository navigation
Allow JSON schema id and $schema in OpenAPI schema definitions #1523
JSON Schema files can contain top-level fields id and $schema. When using $ref in an OpenAPI document to reference an external schema, the OpenAPI tooling rejects JSON schema files that contain one or both of these fields because 1) the spec does not allow additional fields and thus 2) the published JSON Schema document for OpenAPI does not allow additional fields.
See https://github.com/whitlockjc/swagger-lint/issues/11 for some specific examples.
I propose changing the spec and the corresponding OpenAPI 3.0 schema to allow id and $ref so that one can publish OpenAPI model definition as JSON schema documents. This will allow more tools to consume them more fully.
Note: I am not requesting OpenAPI change the allowed subset of JSON Schema features.
This issue will be addressed if we can make headway on the alternate schema proposal. Whitelisting certain properties I fear will just open the door to whitelisting "just one more property" and the end result will be confusion as to what tooling supports, ignores and doesn't support.
Thanks, @handrews but I don't need to go that direction. I'm designing the schema as part of our OpenAPI. I just want to publish them as full JSON Schema that contains id & $schema (in fact, right now I define the schemas as components in the OpenAPI spec, and then extract them to JSON Schema files as part of our build/deploy toolchain. The output schema are available to both OpenAPI and to other tools such as form builders. My workaround is to generate a model.json without id and $schema ($refable from the OpenAPI docuemnt) and a sibling schema.json with id and $schema, usable by tools consuming JSON Schema. I'm emitting both from the same openapi.yaml. I'm hoping to eliminate the need for managing/deploying both files or other run-time filter shenanigans.
Activity
darrelmiller commentedon Apr 3, 2018
This issue will be addressed if we can make headway on the alternate schema proposal. Whitelisting certain properties I fear will just open the door to whitelisting "just one more property" and the end result will be confusion as to what tooling supports, ignores and doesn't support.
handrews commentedon Apr 16, 2018
@DavidBiesack in the meantime you may be interested in https://github.com/wework/json-schema-to-openapi-schema to help bridge the gap (or something else similar)
DavidBiesack commentedon Apr 17, 2018
Thanks, @handrews but I don't need to go that direction. I'm designing the schema as part of our OpenAPI. I just want to publish them as full JSON Schema that contains
id&$schema(in fact, right now I define the schemas as components in the OpenAPI spec, and then extract them to JSON Schema files as part of our build/deploy toolchain. The output schema are available to both OpenAPI and to other tools such as form builders. My workaround is to generate amodel.jsonwithoutidand$schema($refable from the OpenAPI docuemnt) and a siblingschema.jsonwithidand$schema, usable by tools consuming JSON Schema. I'm emitting both from the sameopenapi.yaml. I'm hoping to eliminate the need for managing/deploying both files or other run-time filter shenanigans.mulib commentedon Feb 28, 2019
any update on this?
currently (at least in swagger hub) ids does not works
it will be great if swagger accept the standard JSON schema syntax
philsturgeon commentedon Jan 9, 2020
Added in #1977 so we can close this.
philsturgeon commentedon Jan 9, 2020
Swagger is a brand, a trademark for a suite of tools. OpenAPI has accepted $id.