santhosh-tekuri/jsonschema

make Schema fields public

Closed this issue · 12 comments

juliaogris commented

Hi and thanks for this great package.

This is an enhancement or change request rather than a bug report:
Please consider making the jsonschema.Schema struct fields public to allow for post-processing the compiled Schema - I'm happy to attempt a PR.

More details on why this is required: .
We are working on a system where users can submit arbitrary JSON Schemas and then submit data that is validated against them. For our purposes we would like to limit some JSON Schema properties:

  • no usage of allOf, anyOf, oneOf, dependencies, not, additionalItems
  • additionalProperties must be false
  • type is always required and must be specified as string (single type, not set of types).
  • array must be of a single type, specified with: "items": { "type": "..." } etc.

We would also like to allow for backwards compatible schema updates which means validating one schema against another older one.

Thanks for your thoughts!

handrews commented

I would just write a custom meta-schema that enforces these restrictions and validate your schemas against that, rather than trying to make a much deeper change to a specific implementation.

juliaogris commented

Thanks, yes we have considered this.
However, to enforce backwards compatibility between schema versions (ie only additional properties and enum fields allowed, no additional required fields after initial version) I believe this would not work or at least be more complex than processing the Schema struct in code. Am I missing something?

handrews commented

Hmm... so you want to compare an older and newer schema and figure out whether the differences are within your allowable policy? Interesting. I read the comment too fast at first and did not catch that.

Yeah, you'd want to be able to process it. Not clear to me what you would need from this package as opposed to just loading the JSON into a Go structure directly and working with that. Just trying to brainstorm different ways of getting this done. Does that part need to be done in Go?

juliaogris commented

Thanks for your comments.

The system is written in Go so I'd prefer to stay in Go unless you have a compelling idea to use something else?

I think you are right, there is not much needed specific to this package in order to process the schema. I'd like to use this package though for the actual data validation and I believe that the jsonschema.Schema struct is already pretty close to the required Go structure I'd have to create for my processing.

I could copy it I guess, but I think it might not be trivial to populate it - so then the question is if I might be better off forking jsonschema and also using it for the required schema limitations listed above?

handrews commented

I'm just dropping in from the JSON Schema spec project (sorry, I forgot to mention that, usually I'm better about that), so I'll leave it to @santhosh-tekuri to answer the rest. It might be quite easy for all I know!

I spoke up mostly because we're looking at how to better support different variations in keyword vocabulary for draft-08, and a big part of that is making custom meta-schemas more usable (without losing the information about what you're customizing, which is the problem today- if $schema isn't one of the standard meta-schemas there's not much an implementation can guess about it).

juliaogris commented

Ok, thanks a lot for clarifying.
FWIW I think JSON Schema is great. Thanks for introducing me to metaSchema. It seems quite clear at a first glance so I think I will have a look at it for the schema restrictions we want.
I still think I might benefit from accessing the jsonschema.Schema struct though.

handrews commented

@juliaogris thanks! And yes, for what you are wanting to do I agree that would help.

santhosh-tekuri commented
  1. If you want to restrict the way jsonschema is defined, as @handrews suggested, using meta-schema is best approach
  2. to verify whether schema updates are backward compatible, making Schema struct fields public is best one
  3. there might be other use-cases where making Schema fields public will be useful. for example: converting json-schema from one version to another
    Reading json-schema into go struct as suggested is not straight forward. resolving $refs complicate the solution.

I can make the fields to public in new git branch, because it needs some work like:

  1. documentation
  2. check if the fields are appropriate. we use single struct for versions of json-schema. I want to avoid field changes in future which might break backward compatibility.
juliaogris commented

@santhosh-tekuri - thank you very much for getting back so quickly and being open to the idea!

All your suggestions sound good. I've pulled together a version of jsonschema with most jsonschema.Schema fields public at my fork. I've only made fields public that I needed. It worked like a charm, I had a draft of my "backwards compatibility" schema validation ready in no time - compliments to the clarity of the data structure.

If you want I could document it under your guidance and issue a PR, but I'm equally happy to leave it entirely up to.

Thanks again!

santhosh-tekuri commented

@juliaogris except enumError field rest of them are exported

juliaogris commented