Episode 202: Ben Hutton on JSON Schema  ## Metadata - Author: [[Sustain]] - Full Title: Episode 202: Ben Hutton on JSON Schema - Category: #podcasts - URL: https://share.snipd.com/episode/0d7c5ed5-c229-4cdd-ad2d-22871e1148e8 ## Document Notes ## Highlights - **Future Vision for JSON Schema** - The vision for JSON Schema is to be a single source of truth across the entire development stack, from data modeling to UI generation. - Achieving this requires industry buy-in and new extensions to reduce ambiguity and broaden applicability. Transcript: Speaker 1 My personal vision, I know other people have some slightly different visions for JSON schema and working all that out. My personal vision is I'll be able to see JSON schema used throughout the whole stack of development right away from inception, to defining your data structures and your models, defining What those different domains that like, to defining database structures, to defining forms and the validation used across that whole stack where you have data in any way, shape or Form and it being a single source of tree, all of them. We did a case study with a company called open metadata where they actually use JSON schema across their entire stack. The person I interview with, you can check out the video recording of the case study, previously worked for Uber and built up all of their infrastructure and data processing operations Using JSON schema and trying to work in this way, but really struggled and the ecosystem just wasn't quite mature enough at that time. As it's evolved and developed, it has reached a point where they can use it across the entire stack. I think they got lucky. I think they were fortunate enough to either find tools that made the assumptions they wanted or to be able to add tools or bits of the stack that didn't exist, had the assumptions they Wanted or they could define the assumptions they wanted to happen in place of not having a sufficient language to define what they want. I think they got really lucky, but I would like anybody to be able to do that. In order to do that, we have to define how to release the ambiguity with co-generation or form generation or various UI generation, documentation generation. There's lots of extensions we need to define in JSON schema to be able to cater for those use cases. The only way that's really going to work is if we can get buy-in from different industries and different enterprises and companies and organizations that rely on those specific areas Of technology. I think I mentioned earlier that the standards process isn't necessarily just about coming to consensus and defining something that people agree ([Time 0:24:32](https://share.snipd.com/snip/801c29b3-4789-4ddb-a163-a5c904eba7e8)) - **Sustain JSON Schema Ecosystem** - JSON Schema funding and sustainability depend on sponsorship and community support, especially for maintaining implementations. - Supporting library developers ensures ecosystem interoperability and long-term project health. Transcript: Speaker 2 Is great. If they're paid for their time and then this extension is made, none of that money normally goes back to JSON schema. I'm curious, what are the financial needs for JSON schema that are outside of people being paid during the normal jobs for this work? Do you feel that people who make money off of knowing the schema and working together with JSON schema should be donating back in some sort of guild tax or something or membership fee Or being part of the community in the first place and so utilizing its efforts to do good work? Speaker 3 I think where JSON schema is now, we're quite happy in terms of the sponsor share. Speaker 1 We've got free placement being able to have several people working full time. I think if placement was to decide they didn't want or need to support that effort anymore, we would probably be able to find other venues that were looking to support those kinds of activities Or would give back to full time work and do it on the side. We definitely want to make this scheme more maintainable. One of the objectives we had from a recent summit, only the ship summit in JSON schema, we ended up drawing a roadmap and we want to assess our financial stability. What does it really cost to run JSON schema? What are our goings? In terms of infrastructure, it's relatively less so we host our site on GitHub and we proxy it through Chadflare, but the real cost is quite cheap. Other than people's time, there's not really any cost. I think that's one of the interesting things about being a standard as opposed to an open source product or open source tool that self-hasts. There are definitely potential revenue streams for commercializing side projects. I know some people in the community are doing that and there's some really interesting things developing. But yeah, I don't really know. I think that's something that I'd be interested in exploring and seeing if people want to contribute. I think there's definitely a sense of JSON schema could be supporting and encouraging development of implementations and helping them become more compliant. It is the ecosystem growth and develops and stabilizes and increases the level of interoperability it has. The people that use JSON schema and rely on JSON schema are going to have their value increased and they're not necessarily going to know where that money needs spending or even how to Allocate and assess the quality of the implementations. That's one of the big things to work with. Starting to do over the next year is how to be a Cess implementation quality, how to make sure they're running the test suite. Then if we have more funds, how can we share those funds out between implementations that are trying to move towards compliance and how do we support and sustain those implementations? They get to fix bugs or have increased users that have problems or issues that they're raising. ([Time 0:27:11](https://share.snipd.com/snip/0e2fd203-4e35-4a2a-969f-96bb4c1a846f)) - **Key Threats to JSON Schema** - JSON Schema's main threat is not forked standards but the replacement of JSON itself. - JSON remains popular due to its simplicity, which supports JSON Schema's continued relevance. Transcript: Speaker 2 To be redone? Speaker 1 There have definitely been other similar projects that have come and gone on the start. Other projects that are trying to do something very similar to JSON schema, but are successfully different or focused on a particular use case or have a particular commercial product Attached. JSON schema doesn't have those things. I think the biggest threat would be if something were to replace JSON, but then I think we're going to have a lot bigger concerns than JSON schema if that's what happens. We should talk about XML. I don't know. I think as a community of developers at large, we've tried to move past that and JSON is the most popular because it's the easiest. People complain about JSON in general for having too many code marks or being too verbose, and often common challenge or question like, why is it so verbose? Why can't we have comments? Why can't we have this? Sometimes the simplicity is what makes it so powerful. And as similar with JSON schema, JSON schema, you can just use the simplest parts and use the smallest bit that you need. I think that's what makes it powerful. It can be really easy to learn. There are some more advanced things in the data sphere like RDF or linked data. And they're really interesting and they're really powerful for science that need to do more complex things, like do ontology comparisons and do some really clever data analysis of Ontological data. But they're really hard to learn. So people really can't get my traction with them in honesty. People that people see the value that they might provide, but really struggle to get unboarded them. And there are similar standards in that space that are trying to use linked data. But again, it comes back to JSON. It's the simplest that we have at the moment. So if we have that with anything simpler, that's not YAML, that S3 pool, it confused because it's complicated, then yeah, maybe we'll see something ([Time 0:31:30](https://share.snipd.com/snip/91c52276-f849-4a19-ab1c-def15ef07173))