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

[Feature] Expose AST #88

Open
skyzyx opened this issue Jan 3, 2021 · 2 comments
Open

[Feature] Expose AST #88

skyzyx opened this issue Jan 3, 2021 · 2 comments

Comments

@skyzyx
Copy link

skyzyx commented Jan 3, 2021

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:

  1. Read and parse the schema.
  2. Read and parse the JSON.
  3. Iterate over both to figure out what's valid/invalid.
  4. 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.

@Arqu
Copy link
Contributor

Arqu commented Jan 3, 2021

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.

@mitar
Copy link

mitar commented Nov 1, 2021

I would also like to be able to access AST so that I could make a linter.

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

No branches or pull requests

3 participants