Closed halvko closed 4 months ago
Thank you for this. I'd like to support multiple JSON schema versions, but in a "version-aware" way rather than a "permissive" way. I hope to write up a larger issue with my current thinking, but in general, I think I'd like to process each supported version with strict adherence to its spec, and dump that into an intermediate format. This would, for example, handle the incompatible changes to tuples in the 2020-12 spec. This may be taking on too much, but I've conflated this work with support for external references, dynamic references, as well as improved json path-based error messages.. so at a minimum I'd like to get my head around it all to sequence the work reasonably.
I need to interact with an API specified using JSON Schema draft-03.
cargo-typify
errors during serialization of that API. The issue is therequired: [bool]
notation used on object properties in pre draft-04 versions of JSON Schema. The following is a minimal example where the serialization fails:This happens because
schemars
defines therequired
field as following:Since
required
have a wrong type,serde-json
fails trying to deserializing the above example to anObjectValidation
.To fix it for our use, I implemented parse-jsonschema to seperate the structure parsed into from the internal representation used, and correctly transforms the old required structure to the new.
I have used this in
cargo-typify
in our fork of typify (found here).If you are interested in supporting the old
required
syntax intypify
, I am ready to put in some time to make it ready for upstreaming, otherwise, feel free to close this issue.Some notes on our current implementation:
I choose to create a separate structure from the one in
schemars
, since the structure inschemars
seems to mainly be used for generating JSON Schema. It would be less fit for that purpose if it was modified to support serialization from any JSON Schema found in the wild.The current implementation does not take the specified version of the JSON Schema into account. I have not checked the current specification to see if it disallows
required
fields in different contexts than the use in object schemas.In our fork of
typify
the only crate which currently works iscargo-typify
. I have not looked into why.