Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON Schema bundling formalised

json-schema.org

Post reply on HN
Print view View original

31–40 of 188 posts

Re: JSON Schema bundling formalised

#31

Post by brabel »

oefrha wrote: post #10
sorokod wrote: post #6

Would be good if there was a clear statement about who the authors are and what makes their content authorative.

> 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://j…

It's a horrible mess, made worse by the several years in which OpenAPI defined their own "dialect" of json-schema for their data schemas which was incompatible with the non-OpenAPI variant of json-schema, so you get libraries that support both, or support only a certain version of each, and because different versions tend to be completely incompatible with each other, you might run into lots of problems if you have more than one language consuming schemas, or even the same language but using different libraries due to transitive dependencies... it's just terrible, just use XML if you need a schema.

Re: JSON Schema bundling formalised

#33

Post by tored »

RustyRussell wrote: post #23

I use jsonschema to validate my projects' output, and also generate the documentation from it. The python jsonschema support makes this possible: our testsuite is in Python already. But it's an awkward fit, and I despair of having anyone else in my team write schemas: the default of allowing additional unspecified fields must be continually overridden, otherwise your schema has no teeth, and things like "if this fiel…

Yes, the unspecified fields is a nuisance.

It is hard to manually look at JSON data and compare it visually to a JSON schema because the schema has a depth to every property and lots of other cruft, which makes it somewhat cumbersome to retrofit a JSON schema to existing JSON data.

I once developed an alternative JSON schema internally for a company where the structure was the same as the JSON data (and default strict of course). We implemented multiple implementations for every language we used. It sort of worked, not as feature complete as the official JSON schema of course, but my conclusion is that JSON doesn't fit well for this.

Re: JSON Schema bundling formalised

#34

Post by tored »

jacobmischka wrote: post #18

I'd like to offer a contrasting opinion to all of the other currently negative comments: I've used JSON schema in the past to validate outside input and it was a pleasant and straightforward experience. There are unfortunately no standard type declarations that I'm aware of, which is a pain, but tools exist to translate schema.org schemas[1] (I have not used this myself). [1]: https://github.com/charlestati/schema-or…

When I used JSON schema last time a few years ago the different implementations of it in PHP and nodejs where either incorrect of feature incomplete. Seems like it is hard to get right.

Re: JSON Schema bundling formalised

#35

Post by yarcob »

akie wrote: post #3

I 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…

Let's say you have some code that takes some JSON as input, and then iterates over the elements of some array in that JSON. Since JSON is schemaless, you need to check whether the array you want to iterate over is actually and array, and for each item you have to check if it has the correct type. Each time you access any data in the JSON you need to validate if it has the correct type, or you will end up with runtime errors.

All that validation takes a lot of effort and makes your code hard to read.

If you verify that the JSON input matches the expected schema at the very beginning, you can skip all the validation and error handling later, since you already know that is valid. This would make it a lot safer to handle external input.

Then the next step would be if language & tooling also supported JSON schema, so that the way you access JSON documents in code also doesn't violate the schema. This would help prevent bugs from programmer errors.

Re: JSON Schema bundling formalised

#37

Post by Jenk »

jonny383 wrote: post #15

If someone tried to push this on my engineering team, they would be laughed out of my office and ridiculed for the idiocy of even suggesting such garbage. The best factor of JSON is being a schema-less, human readable format. Imagine having someone present this monstrosity to you with a straight face, thinking it's a good use for JSON.

Do you prohibit the use of VSCode in your workplace? Anyone using that is using jsonschema. It's built into the applicatoin for its settings and configuration files. Plugins and extensions use it to manage their own config _and_ as validation for the editor's api.

Re: JSON Schema bundling formalised

#38

Post by tored »

ChrisMarshallNY wrote: post #20

I generally prefer using JSON in my interactions, where possible. That's because it is lightweight, and 99.9% of the data I'm transferring is scalar. JSON is basically "implied" for scalar types. The good thing (if you want to call it "good") about XML, is Schema. Schema is a "rock hard" contract. It is definite, empirical, unambiguous. When I am looking at an API, and it has a Schema, then I know that I can figure o…

One thing I'm guilty of is designing a document format as JSON, thus the need to formally verify it.

Passing data works well as JSON but documents works better as XML where you can use XML Schema.

Re: JSON Schema bundling formalised

#39

Post by oefrha »

brabel wrote: post #31
oefrha wrote: post #10

Earlier quoted context omitted.

> 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://j…

It's a horrible mess, made worse by the several years in which OpenAPI defined their own "dialect" of json-schema for their data schemas which was incompatible with the non-OpenAPI variant of json-schema, so you get libraries that support both, or support only a certain version of each, and because different versions tend to be completely incompatible with each other, you might run into lots of problems if you have m…

The language is a godforsaken monstrosity, but if you only have to write it once for some non-critical validation task it’s acceptable. For instance, I use JSON schema to (optionally) validate some generated JSON data which is fed into a web app as a JSON module. I also generated the TS spec for it from the JSON schema (although writing the TS spec by hand would have been 10–100x easier than writing the JSON schema). XML is obviously not suitable here — TypeScript doesn’t have XML modules.

Re: JSON Schema bundling formalised

#40

Post by vultour »

Jenk wrote: post #37
jonny383 wrote: post #15

If someone tried to push this on my engineering team, they would be laughed out of my office and ridiculed for the idiocy of even suggesting such garbage. The best factor of JSON is being a schema-less, human readable format. Imagine having someone present this monstrosity to you with a straight face, thinking it's a good use for JSON.

Do you prohibit the use of VSCode in your workplace? Anyone using that is using jsonschema. It's built into the applicatoin for its settings and configuration files. Plugins and extensions use it to manage their own config _and_ as validation for the editor's api.

Your editor has nothing to do with your product. People use PyCharm to write Python yet would "laugh out" anyone who suggests to start writing Java.
Post reply on HN