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

[JSON Schema] Support for schema.Reference #36

Open
smyrman opened this issue Aug 23, 2016 · 4 comments
Open

[JSON Schema] Support for schema.Reference #36

smyrman opened this issue Aug 23, 2016 · 4 comments

Comments

@smyrman
Copy link
Collaborator

smyrman commented Aug 23, 2016

UPDATED

This ticket is now about extending schema.Reference support in the schema/encoding/jsonschema package when adding support for the OpenAPI Specification (a.k.a. the Swagger 2.0. specification).

More specifically, schema.Reference fields should be encoded as {"$ref": "#definitions/<unique resource path>/id"} when encoding a schema for an OpenAPI Specification resource.

This might require:

  • The ability to "name" a schema when adding it to the Index.
  • Changes the schema.Reference or grant access to the Index to the encoder.
  • The ability to turn on/off a JSON Schema encoding "extension".

PS! This ticket is currently blocked on adding initial support for the OpenAPI Specification.

@rs
Copy link
Owner

rs commented Aug 23, 2016

Yes, you can't modify the content of the reference from the parent document in the current state of the code.

@smyrman
Copy link
Collaborator Author

smyrman commented Dec 12, 2016

(...) As you can imagine, this poses a small problem, as we would presumably need access to the index.

For JSON Schema used with the Swagger 2.0 specification (a.k.a. OPEN API Specification), we can actually avoid the resource.Index dependency completely by using the "$ref" keyword. If we can accept no type to be defined when using JSON Schema without swagger, this solution could be good enough...

Swagger 2.0 defines all payloads for an API under the "definitions" parameter in the root schema. Therefore, we can refer to the ref validator schema definition as "myRef": {"$ref": "#/definitions/{TypeName}/id"}.

Note that {TypeName} is most correctly spelled singular and possibly capitalized, so it should not be taken directly from the reference path. The reference path can also be deep. This must however be solved anyway to enable Swagger 2.0 documentation, so it's not a Reference specific problem.

@smyrman smyrman changed the title [jsonschema] Support for schema.Reference [swagger] Support for schema.Reference Feb 13, 2017
@smyrman
Copy link
Collaborator Author

smyrman commented Jun 23, 2017

UPDATE: if #100 is fixed/merged, there is an opportunity to access the Validator of the linked ID we are targeting if the schema is registered with a resource.Resource within a resource.Index that gets compiled.

This way we could embed an actual validator for the field rather than a reference, and we do not have to implement Swagger 2.0 support in order to close this issue.

@smyrman smyrman changed the title [swagger] Support for schema.Reference [JSON Schema] Support for schema.Reference Jun 25, 2017
@rs rs added the enhancement label Jul 1, 2017
@smyrman smyrman added this to the 0.2 Minor stability release milestone Nov 23, 2017
@smyrman
Copy link
Collaborator Author

smyrman commented Sep 19, 2018

UPDATE: if #100 is fixed/merged, there is an opportunity to access the Validator of the linked ID we are targeting if the schema is registered with a resource.Resource within a resource.Index that gets compiled.

The way this has been implemented, the related validator is kept private. I want to revisit how JSON Schema (and ptentially other doc formats) gets generated after #77, so I am dropping this from the 0.2 milestone.

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

No branches or pull requests

2 participants