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

21–30 of 188 posts

Re: JSON Schema bundling formalised

#21

Post by endisneigh »

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.

You’d laugh at someone for merely suggesting a technology? Seems like a toxic team

If you think it’s bad surely an explanation would win them over and stop their efforts?

Re: JSON Schema bundling formalised

#22

Post by chmod775 »

conceptme wrote: post #14
chmod775 wrote: post #11

A yes. Because things like "integer" totally need to be abstracted away into another schema. Couldn't have given this DSL built-ins for the things that are... you know... built into JSON already. Also bonus points for the apparent lack of shorthands, turning this language into a verbose word salad. I hope there's at least a line of reasoning that explains why some keys are prefixed with '$' and others aren't. Great w…

afaik there is no integer type in json but a numeric type, and most languages do have different numeric types.

Neither is 'non negative' - but that should also be a built-in, considering how verbose the language becomes otherwise.

Now you're adding ~5 lines of boilerplate every time you want to have an integer, another 5 for positive integers, and so on.

Re: JSON Schema bundling formalised

#23

Post by RustyRussell »

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 field is this value, these additional fields exist" must then always have an "else" indicating that no additional fields exist.

In summary, it's better than nothing, but it's not easy. I'm not sure that JSON is a great language to specify schemas in, sorry.

Re: JSON Schema bundling formalised

#26

Post by johnnycerberus »

hyperpallium2 wrote: post #4
csmpltn wrote: post #2

We'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…

back to CORBA

> CORBA

"Well, it's high noon somewhere in the world."

Re: JSON Schema bundling formalised

#27

Post by Someone »

chmod775 wrote: post #11

A yes. Because things like "integer" totally need to be abstracted away into another schema. Couldn't have given this DSL built-ins for the things that are... you know... built into JSON already. Also bonus points for the apparent lack of shorthands, turning this language into a verbose word salad. I hope there's at least a line of reasoning that explains why some keys are prefixed with '$' and others aren't. Great w…

https://json-schema.org/draft/2020-12/json-schema-core.html#...

This document defines a core vocabulary that MUST be supported by any implementation, and cannot be disabled. Its keywords are each prefixed with a "$" character to emphasize their required nature. This vocabulary is essential to the functioning of the "application/schema+json" media type, and is used to bootstrap the loading of other vocabularies.

Re: JSON Schema bundling formalised

#28

Post by reaperducer »

66fm472tjy7 wrote: post #8
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…

There are things you cannot accept. What do you do if an order has a negative quantity, if you get a string instead of a number, if a value does not fit in your DB column, etc ? 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…

What do you do if an order has a negative quantity, if you get a string instead of a number, if a value does not fit in your DB column, etc ?

Isn't that all just basic data validation and sanitation that we all do anyway? And wouldn't it still have to be done, even if the JSON came with all the schemabloat?

I don't think I'm suddenly going to accept that the data presented to my function is valid and fit for purposes just because it goes through someone's JSON schema library. That's just passing the responsibility on to a third party, which feels lazy and dangerous to me.

Maybe it'll be OK for systems that don't get unusual data. But mine are always ingesting strange things, and the only person who knows what's truly valid and what's not is me, not a third party. That's my responsibility as the programmer of the system.

I looked through the web page, and it's probably great for someone. Somewhere. But I'd like to see that SKU example that was presented fully fleshed out with real-world type data. It seems OK if your data only consists of "productID," "productName," and "productTags." But in real life, SKUs are often incredibly complex, and this just seems to invite disaster by making complex systems even more complex. So much so that they require even more complex tools to manage them.

Re: JSON Schema bundling formalised

#30

Post by jonathanlydall »

66fm472tjy7 wrote: post #8
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…

There are things you cannot accept. What do you do if an order has a negative quantity, if you get a string instead of a number, if a value does not fit in your DB column, etc ? 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…

I feel exactly the same.

I also want to add that consumers with an appropriate framework can automatically generate a response body explaining where in the payload that errors were encountered and what those errors are. This allows API consumers to understand what is going wrong far more easily that a 500 being returned.

ASP.NET for example can do exactly this with validation on incoming payloads.

If the payload is invalid, then either way there will be an error, but it's nice to be able to give more helpful errors.

Post reply on HN