JSON Schema bundling formalised
json-schema.org
JSON Schema bundling formalised
1–10 of 188 posts
Re: JSON Schema bundling formalised
#2We should consider restricting the registration of .org domains to actual non-profit organizations, and restricting the use of words like "schema" and "standard" to things that have been fully certified as such by internationally accredited engineering bodies.
This doesn't add anything on-top of the tools we've had 40 years ago. We're stuck with this everywhere now, all thanks to pure marketing.
Re: JSON Schema bundling formalised
#3I'd rather live by the old maxim "be liberal in what you accept, and strict in what you produce". But perhaps I'm overlooking an important use case here, in which I'd happily stand corrected.
Re: JSON Schema bundling formalised
#4We've come full circle back to XML SOAP. We should consider restricting the registration of .org domains to actual non-profit organizations, and restricting the use of words like "schema" and "standard" to things that have been fully certified as such by internationally accredited engineering bodies. This doesn't add anything on-top of the tools we've had 40 years ago. We're stuck with this everywhere now, all thanks…
Re: JSON Schema bundling formalised
#5Re: JSON Schema bundling formalised
#6Re: JSON Schema bundling formalised
#7I might be exceptionally dense, but it's hard for me to see practical applications for something like this. In the end, if you implement this in your application, you will have a mechanism to say "this input document is invalid". AND THEN WHAT? Your only option is to discard it. I'd rather live by the old maxim "be liberal in what you accept, and strict in what you produce". But perhaps I'm overlooking an important u…
All arguments for and against schemas in databases translate well to this case.
Re: JSON Schema bundling formalised
#8I might be exceptionally dense, but it's hard for me to see practical applications for something like this. In the end, if you implement this in your application, you will have a mechanism to say "this input document is invalid". AND THEN WHAT? Your only option is to discard it. I'd rather live by the old maxim "be liberal in what you accept, and strict in what you produce". But perhaps I'm overlooking an important u…
Having this as part of your interface definition, along with generated representations of the possible data in the language your choice[0] and automatic (so you can't forget it) validation that rejects invalid input with HTTP 400 bad request instead of 500 internal server error when the DB constraint fails (or even worse, you persist invalid data and something breaks later) is definitively useful.
That said, OpenAPI fails at this somewhat as the people writing the spec don't consider the (de)serialization and validation libraries. Thus, OpenAPI keeps adding features/constraints that are not supported by the libraries and are thus cannot be automatically validated or even produce nonsense output on generation (e.g. in Java you might end up with raw Map or even Object fields)
Re: JSON Schema bundling formalised
#9History has not been kind to efforts like these.
Re: JSON Schema bundling formalised
#10Would be good if there was a clear statement about who the authors are and what makes their content authorative.
Nothing, it’s just relatively widely known and used (e.g. for VS Code and Windows Terminal config files, which I expect a lot of people to have experience with), with relatively good library support in a wide selection of languages. Although I should mention that most of the libraries are stuck on old versions, and the versions they’re stuck on are all over the place: https://json-schema.org/implementations.html