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

Is this proposal active for feedback? #6

Open
handrews opened this issue Oct 13, 2022 · 6 comments
Open

Is this proposal active for feedback? #6

handrews opened this issue Oct 13, 2022 · 6 comments

Comments

@handrews
Copy link

Hi @SrikrishnanS @bchammer @GabenGar — is this project active? I have some thoughts on the proposal but would like to see if it's worth writing them up before I do.

@bchammer
Copy link
Member

bchammer commented Oct 13, 2022 via email

@GabenGar
Copy link
Contributor

Is this going to be an Oracle DB Schema? I am not an expert, but looking at the postgresql JSON docs there are slight differences between normal json and binary one. It's not generally a problem when the application layer is responsible for data validation, since it can pick and choose the storage format (and eat up the problems associated with the choice). But when DB also can validate the input data which can subtly change between formats and also need a slightly different schema for that, it can easily end up in a non-trivial situation where the application and the database don't agree what constitutes a valid input json.

@handrews
Copy link
Author

Thanks, @bchammer ! If you're at the point of showing stuff already, I'm guessing a lot of the decisions are fairly settled, and I'm not trying to undo that.

I've been thinking about extensibility and the vocabulary system, and how that works or does not work in different use cases. This proposal is interesting because it is a vocabulary, but also it defines other extension mechanisms: specifically, extendedType allowing additional values and falling back to annotation behavior. This is obviously along similar lines as format, which has often caused problems in terms of reliable behavior.

In a different environment, I would have recommended allowing vendors to specify additional keywords/vocabularies rather than additional values on a single keyword, but doing that requires defining a meta-schema to include the vocabularies, and in a SQL database you are working with a JSON Schema in a SQL string rather than as a set of documents. So I can see how supporting additional keywords/vocabularies within Oracle would be challenging. Where would the custom meta-schema live? There doesn't seem to be an obvious good answer for that.

So I am curious:

  • Did you consider supporting additional keywords/vocabularies instead of extra values for extendedType?
  • If so, was the need to manage vocabularies through a separate meta-schema document the reason you didn't take that approach?
  • Whether you considered it or not, if vocabularies/keywords could be controlled within the single schema (no need to examine a separate meta-schema), would it have been more appealing to use that mechanism?

Please let me know if these questions don't make sense and I'll attempt to clarify. As we work on extensibility for JSON Schema I'm hoping that we can support more use cases and environments with one mechanism.

@emeraldjava
Copy link

Hi @handrews @bchammer @GabenGar — is this project active? Would be interested to see that oracle/postgres schema that was referred to. thanks.

@bchammer
Copy link
Member

bchammer commented Sep 17, 2024 via email

@gregsdennis
Copy link
Member

@bchammer thanks for the interest, however, I wouldn't say that this is active in the way that JSON Schema is an active specification. I'd hesitate to even say it's active in that it's being developed. Work on this has stalled quite a bit.

That said, it's good to have feedback during development on ease of implementation and use, and we need people building prototypes to get that, so thank you.

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

5 participants