qri-io
[Feature] Expose AST
What feature or capability would you like?
I'd like to use this library for things other than validation uses. I am making some assumptions here, but it seems like the general flow is something like:
- Read and parse the schema.
- Read and parse the JSON.
- Iterate over both to figure out what's valid/invalid.
- Return the results.
Focusing on number 1, I'm assuming that you're creating a tree model of some kind to work with. Maybe it's a proper AST, maybe it's not. My request is that you expose this AST for the JSON Schema so that others (like me) can build other things on top of it.
Since JSON Schema is the richest of the formats, one of the things I want to do is write a JSON Schema → Protocol Buffers transformer (using draft 2019-09 and proto3), and another is a JSON Schema → GraphQL SDL transformer (again, using draft 2019-09). Having an AST for the schema would be a great place to start.
Do you have a proposed solution?
I'm assuming this already exists internally. My proposal is to expose it as a public interface, and add it to the semver software contract.
Have you considered any alternative solutions or workarounds?
I've considered writing one from scratch… but I'd prefer to build atop existing (great) work and contribute to that if I can.
Just to offer some quick feedback on this topic (I'll look to come back and give some more exhaustive input when time permits).
These seem like fairly interesting use cases, but I'm concerned on the potential scope of maintaining this especially around compatibility long term.
In general, what you want to look at is schema_registry.go & schema.go as the top level structs. You should be able to serialize Schema to JSON and play with it, but I'm unsure whether that gets you close enough to your target. Some of the top level issues I see coming up here is handling schema references and resolving those (again a lot of this should unwrap on the first load and you can serialize to JSON).
Considering yor top level list/flow, my inclination would be to focus on actually improving the validation output so that it is useful for further processing (I don't think we're fully compliant or correct on that aspect yet).
Finally, I'm unsure about what you mean under adding it to the semver contract, jsonschema already follows the versioning schema to some degree. Obviously intentionally <v1.0.0 for now, as things can break backward compatibility on minor version changes too, like the last rewrite.
Hope this gives at least a starting point for a better discussion.
