[dead]
JSON Schema Demystified: Dialects, Vocabularies and Metaschemas
11–20 of 40 posts
Re: JSON Schema Demystified: Dialects, Vocabularies and Metaschemas
#12I think JSON Schema made the same fallacy as eg. OWL did: The assumption of an open world. 99% percent of the time you want to express "This message should look like this and everything else is wrong". Instead JSON-S went the way to make everything possible at the price of rendering the default unwieldy.
There's a way to express that though: by adding `"unevaluatedProperties": false` underneath your properties list.
Re: JSON Schema Demystified: Dialects, Vocabularies and Metaschemas
#13I'm working with JSON schema through OpenAPI specifications at work. I think it's a bit of a double-edged sword: it's very nice to write things in, but it's a little bit too flexible when it comes to writing tools that don't involve validating JSON documents. I'm in the process of writing a toolchain of sorts, with the OpenAPI document as an abstract syntax tree that goes through various passes (parsing, validation,…
I used to believe that I was working with JSON schema through OpenAPI 3.0, but then I learned a hard lesson that it uses an “extended subset” of it. And what does that mean? It “means that some keywords are supported and some are not, some keywords have slightly different usage than in JSON Schema, and additional keywords are introduced.” [1]. Yes, that’s a bonkers way to say “this is not JSON schema although it look…
OpenAPI 3.1 replaced the not-a-superset-or-subset of JSON Schema with the actual JSON Schema (latest version) over five years ago. No one should be using 3.0.x anymore. And 3.2 came out a few months ago, containing lots of features that have been in high demand (support for arbitrary HTTP methods, full expression of multipart and streaming messages, etc).
Re: JSON Schema Demystified: Dialects, Vocabularies and Metaschemas
#14JSON schema is nice overall* but every software only supports ancient versions like draft 4 *even if I would prefer more transformation/conversion features that would bring it to more more a parser rather than only a validator
Not really true? There are lots of validators supporting the most recent version: https://json-schema.org/tools?query=&sortBy=name&sortOrder=a...
Re: JSON Schema Demystified: Dialects, Vocabularies and Metaschemas
#15The metaschemas are useful but not strict enough. They don't set `additionalProperties: false`, which is great if you wanna extend the schema with your own properties, but it won't catch simple typos.
For example, the following issues pass under the metaschema.
{"foo": {"bar": { ... }}} # wrong
{"foo": {"type": "object", "properties": {"bar": { ... }}}} # correct
{"additional_properties": false} # wrong
{"additionalProperties": false} # correctRe: JSON Schema Demystified: Dialects, Vocabularies and Metaschemas
#16I think the post is generally pretty good. There are some things that I would have stated differently.
"Unfortunately, [the terms] leaked into the documentation that everyone reads" - We did this on purpose to align everyone's terms. It makes things so much easier when the people asking and answering questions are using the same language.
"The official JSON Schema website has a validator you can try: https://www.jsonschemavalidator.net/" - Would have been better to point to the actual official JSON Schema website's tools page (https://json-schema.org/tools) that lists many online validators.
There are some interesting conceptions of OpenAPI in here as well. Specifically, OpenAPI isn't a JSON Schema document. It's its own kind of document that has JSON Schemas embedded in it.
Still, it's a decent high-level summary. If you're interested in diving a bit deeper, definitely come visit us in Slack (https://json-schema.org/slack).
Re: JSON Schema Demystified: Dialects, Vocabularies and Metaschemas
#17The metaschemas are useful but not strict enough. They don't set `additionalProperties: false`, which is great if you wanna extend the schema with your own properties, but it won't catch simple typos. For example, the following issues pass under the metaschema. {"foo": {"bar": { ... }}} # wrong {"foo": {"type": "object", "properties": {"bar": { ... }}}} # correct {"additional_properties": false} # wrong {"additionalP…
This is intentional because unknown keywords are permitted with JSON Schema 2020-12 and prior. We are changing this with the upcoming version, which means we'll be updating the meta-schema to enforce it as well.
Re: JSON Schema Demystified: Dialects, Vocabularies and Metaschemas
#18The deeper principle here: "stop lying about where truth lives." I've been exploring how this generalizes beyond side effects. Every React state library creates a JavaScript copy of state that must sync with the DOM. This is the original sin. Two truths = lies. The solution isn't better syncing, it's refusing to duplicate. The DOM is already a perfectly good state container. All you have to do is read it. Releasing a…
Sounds interesting, do you have any links to these projects? Could not find multicardz when searching
I am dark at the moment.
I am doing final testing, packaging, integrating strip, etc. My target was before end of month. If I work hard I just might make it.
I'm releasing a bunch of things at once: 1. multicardz.com 2. a paper on using DOM as single source of user state dataos.software 3. an OSS repo of hyper performant implementation of that for React (stateless.software) 4. an OSS repo that might best be described as Tailwind for frontend behavior. (genX.software)
they are all somewhat interconnected
Re: JSON Schema Demystified: Dialects, Vocabularies and Metaschemas
#19Re: JSON Schema Demystified: Dialects, Vocabularies and Metaschemas
#20JSON schema was nice when it was simple. Now it feels like writing a validator is extremely complicated. IMO, the built-in vocabularies were enough, and keeping it simple would provide more value. JSON as a format didn't win because it supported binary number encoding or could be extended with custom data types -- but rather because it couldn't.
I'm currently rebuilding my implementation JsonSchema.Net from the ground up. I completed 95% of it in a weekend, and it already supports all the published versions Draft 6 and later, including the more complex keywords. Granted, I have a particularly deep understanding of the spec already, but it doesn't feel overly burdensome.