iglu-central

Back in the early years of Snowplow, we adopted a similar approach for our support of 3rd party webhooks[1] as an event stream source supported natively by Snowplow (https://github.com/snowplow/snowplow). (The important background here is that all events and entities flowing through Snowplow are described using versioned JSON Schema). We built a kind of Maven Central for 3rd party webhooks' schemas[2], and got to work adding schemas for various popular webhooks, e.g. Sendgrid and Pingdom. But, we never met a single SaaS vendor who was interested in 'adopting' the JSON Schemas for their webhook, let alone publishing versioned JSON Schemas for their whole API. This meant that at Snowplow we have stayed on the hook for keeping these vendors' webhook schema definitions up to date in our registry. It's a real tragedy of the commons - oceans of

As far as I know, Snowplow is one of the largest active users of JSON Schema, and we maintain one of the larger repositories of JSON Schemas on the internet, https://github.com/snowplow/iglu-central After something of a hiatus, we are re-starting active work on our schema registry technology (https://github.com/snowplow/iglu). We'd love to be involved in new design work on the JSON Schema spec. How do we get the old (or new!) band back together?

Shameless plug - our Iglu Central is a central repository for commonly-used JSON Schemas. It's here: https://github.com/snowplow/iglu-central You can think of it like RubyGems.org or Maven Central but for storing vendored, versioned data schemas instead of code.

Cool post! After a fair bit of trial and error, we've got a pretty robust JSON Schema for the PerformanceTiming API here: https://github.com/snowplow/iglu-central/blob/master/schemas... We send that in as a custom context in the Snowplow JavaScript Tracker: https://github.com/snowplow/snowplow-javascript-tracker/blob...

It's great to see this! We've been bitten by JSON allowing arbitrarily large numbers at Snowplow. This is what a JSON Schema trying to enforce sensible (int64) numeric limits ends up looking like: https://github.com/snowplow/iglu-central/blob/master/schemas...

This is cool! We do a lot of work with JSON Schema at Snowplow. Here's a few suggestions: 1. Semantic versioning doesn't work for schemas. (What's a patch/bug fix for a schema? It's meaningless.) Use SchemaVer instead - http://snowplowanalytics.com/blog/2014/05/13/introducing-sch... 2. Make your schema self-describing so that a given resume instance is associated with its schema version http://snowplowanalytics.com/blog/2014/05/15/introducing-sel... 3. Publish your JSON Schemas to Iglu Central, the first schema registry for JSON Schema - https://github.com/snowplow/iglu-central