Exposing details of the Schema, subSchema, etc by making them interfaces

[j7m4]

Looking at enhancement request #216, if some of the internal details were exposed through interfaces, external libraries could implement JSON generation.

Would this be amenable to the authors? Would a PR be considered?

[johandorland]

The problem I have with exposing subSchema is that I really don't want to expose any internals to the outside world. Not having subSchema exposed means it can be changed without having to care about compatibility problems (just to illustrate, the last PR as of writing changed some types inside of subSchema #224 ). The upcoming draft-08 version of JSON schema has major changes to the way schema parsing must be done and I don't want to potentially hit a brick wall because subSchema needs to fulfill some interface.

That pretty much rules out the possibility to create an external library that does #216 for you using gojsonschema. Having said that I'm not necessarily opposed to having this functionality inside of gojsonschema. In that case Schema only needs something like a CreateDefaultDocument() method.

I'm interested though how you would implement it. If you only use required and default it seems pretty easy and limited in scope, but once you start considering constructs like anyOf, oneOf, allOf and if/then/else things break down very quickly. What would the limits be of such an implementation as you have it in mind right now?

TLDR;
Exposing Schema and subSchema: No
Having this functionality inside the library: Maybe

[j7m4]

The question about how to handle non-required and anyOf/oneOf/allOf is a good one. The answer to the question is that it would depend on the use case. For example, for the case of oneOf, a reasonable behavior would be to randomly select one of them.

The above ambiguity demonstrates the need for exposing public interfaces for schema and subschema. Different use cases for json generation would need different -- and possibly custom -- implementations. Having the JSON schema details available outside of gojsonschema (or similar library) is a prerequisite for JSON generation from a schema.

[johandorland]

In those cases I can see your argument why it would make sense to have this functionality separate. This doesn't change my current opinion that I don't want to expose subSchema in its currents state as it was never designed for that.

If it is of any consolidation draft-08 requires implementations to have more modular designs which have to provide users of an implementation to add custom logic. There might be a way of implementing that that makes it possible to expose the internals in a clean way, but since this is a hobby project I'm not going to make any promises on when that's going to happen.

[vazirim]

Hi @johandorland, @xeipuuv, we are working on a project where we need to traverse the Schema structure that results from compilation and generate a type for it in a different language. So we have also encountered the problem that SubSchema and its fields are not public. I wonder if you have reconsidered this issue and/or would be willing to accept a PR that offers a visitor for Schema? @aavarghese