Open Community Working Meeting 2022-09-12

[Relequestual]

📺 See Recording

📎 Attached Doc

⏪ Go To Previous Meeting

Agenda

@Relequestual -> I'm hijacking this meeting to help us focus and discuss the future plans of JSON Schema. I previously hijacked a call to facilitate thinking on direction but we only got halfway through it. So, I'm doing it again as the second exercise planned for previous meeting had to be rolled over. I'll provide some more details before the call about how this is going to work and any pre-work that might be helpful.

Highlights

• Sailboat exercise to think of goals, drivers and blockers

Actions

None, but can be derived from the results of the exercise

Attendees

Account
@Relequestual
@awwright
@jdesrosiers
@handrews
@devinbost

Exercise Details

📎 See document cf. pages 4-7

Brief of goals, drivers and blockers mentioned are as follows :

Goals

• Easy learning curve and provide data validation for all major programming languages.
• Provide a single source of truth for the structure of data.
• Develop a language for enabling Web servers to talk about JSON documents in a hypermedia-enabled way.
• A stable spec that is easy to evolve.
• Resources for developers that include common patterns and best practices.
• Allow “data first” or “schema first” designs to drive development.
• Enable safe versioning, evolution of data.
• Ensure that schema authors can be confident that their schemas will be interpreted and evaluated as expected.
• Ensure that the performance, complexity, and feature-richness of JSON Schema are appropriately balanced.

Drivers

• Remove ambiguity when using prose to describe data.
• Promoting an ecosystem that helps users of the Web.
• Allow people to write schemas once and not change them unless they need to with each release i.e stable specification.
• We often see bad practices or sloppy schemas in use. There’s no reason schemas should be any sloppier than code, especially if data/schema design is driving your process.
• Improving ease of cross-company collaboration.
• Accelerate development productivity and ease of maintaining.
• Concern over implementer adoption rates and comfort levels.
• Concern over how much of JSON Schema behaviour lacks a test suite and lack of consensus within JSON Schema Org over how/whether to test it alongwith how results are communicated.

Blockers

• No formal support for implementers, along with lack of industry-implementer collaboration and feedback.
• No easy to use “JSON Schema explainer”.
• Integration in user agents and standardization of a media type, link relations, minimum interoperability/compatibility requirements
• People assuming JSON Schema is hard.
• Lack of capacity to produce best-practices and design pattern content.
• Need official release and stamp from standardization org to get wider adoption. i.e partly to do with use of word draft.
• Need more tooling to reduce duplication in code.
• No clear prioritization, ordering or focus for resolving issues along with disagreements over the scope and communication role of the test suite.
• Lack of a structure or process to gather feedback from all necessary stakeholders to help ground discussions. i.e the process currently in use is holding us back.

---

[benjagm]

Closing this issue as all tasks are completed. Thanks for your contributions!