JSON Schema Demystified: Dialects, Vocabularies and Metaschemas
1–10 of 40 posts
Re: JSON Schema Demystified: Dialects, Vocabularies and Metaschemas
#2The 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 paper (DATAOS) and React implementation (stateless, <1KB) soon. It's the architecture behind multicardz (hyper-performing kanban on steroids, rows AND columns, 1M+ cards, sub second searches, perfect lighthouse scores, zero state sync bugs). Because there's no state to sync.
Re: JSON Schema Demystified: Dialects, Vocabularies and Metaschemas
#3JSON 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
Re: JSON Schema Demystified: Dialects, Vocabularies and Metaschemas
#4I'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, aggregation, analysis, transformation, serialization...). My immediate use-case is generating C++ type/class headers from component schemas, with the intent to eventually auto-generate as much code as I can from a single source of truth specification (like binding these generated C++ data classes with serializers/deserializers, generating a command-line interface...).
JSON schema is so flexible that I have several passes to normalize/canonicalize the component schemas of an OpenAPI document into something that I can then project into the C++ language. It works, but this was significantly trickier to accomplish than I anticipated.
Re: JSON Schema Demystified: Dialects, Vocabularies and Metaschemas
#5JSON 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.
Re: JSON Schema Demystified: Dialects, Vocabularies and Metaschemas
#6The 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
Re: JSON Schema Demystified: Dialects, Vocabularies and Metaschemas
#7The 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
Re: JSON Schema Demystified: Dialects, Vocabularies and Metaschemas
#8JSON 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.
This and schema support for JSON will always be an ill fitting afterthought. If you really, really need the strictness and correctness (and you most probably don't) XML
has you covered.
Re: JSON Schema Demystified: Dialects, Vocabularies and Metaschemas
#9I'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 looks similar enough to deceive you”. This word game and engineering choice is so bizarre that it’s almost funny.
[1]: https://swagger.io/docs/specification/v3_0/data-models/keywo...
Re: JSON Schema Demystified: Dialects, Vocabularies and Metaschemas
#10I 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.