Open Source

I finally wrote the material I kept telling people I’d get around to. Omnist now has a proper introduction deck and a hands-on tutorial. The deck is language-agnostic — it explains the spec itself, not any one port’s API. The tutorial uses Python to walk through every model and feature with real, working code. Why a deck and a tutorial, not just docs The specification is precise on purpose. Precise documents are a bad place to start. You shouldn’t have to read a spec before you know if something is worth your time. The deck is the fifteen-minute version: what problem Omnist solves, and why the model looks the way it does. The tutorial is for someone who’s already decided to try it. Every example is real, working code, checked and run before it went in the page. It’s built as steps, so you can do them out of order once you know your way around. ...

A library gets proven by people using it. A specification is a harder claim to back up: someone else has to build from your rules alone, without being able to ask you what you meant. I wanted Omnist to become a real document and schema standard, not just a library that happened to do well. So I planned for that early on: get the design out of one language, and check that it actually holds up in several others, before I called any of it a standard. ...

Sixteen years ago, in 2010, I published a paper on formalizing schemas for tree-structured data, like XML and JSON. My goal was to move beyond guesswork: could we mathematically decide if a schema change is backward-compatible? I wanted to see if we could prove schema equivalence, or reliably infer schemas from examples. The research offered a solid theoretical framework, though it remained largely academic. For years, I hoped to build something practical from it. But the demands of a full-time job made finding the time nearly impossible. ...