Open Community Working Meeting 2022-09-06 #233
Description
Agenda
| Topic | Owner | Decision/NextSteps |
|---|---|---|
| ADR for decoupling from IETF1 | @Relequestual | Read the updates at Spec PR #1277 |
| Proposal for post-IETF SDLC | @jdesrosiers | Follow the discussion #234 |
| New Website Work | @jdesrosiers | Deferred to next meeting |
Highlights
-
Other than the website update, all items on agenda were brought up and discussed.
-
Update on website work was deferred for later.
-
How do we decide the reviewers as an organizational practice ?
-
@handrews and @jdesrosiers shared their views on topics ranging from keyword behavior, feature stabiliy, vocabulary systems and releases.
Actions
-
Article distinguishing and clarifying vocabulary, features and keywords
-
Progress report on website work
-
@Requestual to add W3C perspective to the discussion #234
-
Add @handrews to reviewers
-
@jdesrosiers to add comments made by @handrews 1
Attendees
| Account |
|---|
| @Relequestual |
| @jdesrosiers |
| @jviotti |
| @handrews |
| @devinbost |
Details
ADR decoupling with IETF process
Members shared their thoughts on how the IETF process does not work for JSON Schema as an organization. Decoupling ADR then requires documenting the process of trying something different1. Although it is widely agreed upon that the IETF process for the media-type registration and JSON Schema's association with Linux Foundation is legitimacy confirming.
A struggle community faces is getting vendors involved in discussions which is not particular to JSON Schema. As it was pointed out that even with membership in OpenAPI, they too struggle to get stakeholders to become part of the discussions. Therefore, how to ensure due dilligence with other working groups and participation of stakeholders was touched upon.
Post IETF SDLC
@jdesrosiers presented a brief overview of the situation. Briefly put, the aim is a stable specification whose parts can be evolved. Leading from that thought, the next spec would be stable i.e no backward and forward incompatible changes from then on. Along with an ability to flag features like certain features can be flagged unstable and be evolved from there.
A three stage process to add new features to spec is suggested -
Stages
- Proposal Stage
- Discussion, review and decision regarding whether to add feature in the specification
- If added, feature stays for year while it is made sure it is not going to change before reaching a
stablestatus
Regarding Releases
- Once a year, say on January 1st, promote features from
stage-2tostable. - Change the flag in the spec eg.
stage-2tostable 2023release feature. - Evolving spec. eg. bug fixes, non-functional clarification can be updated anytime without waiting for release cycles.
A few concerns were raised regarding the above process and its impact on implementers along with keywords, vocabulary and validation behaviour. The answer provided was, as most of what is being discussed and written is for the process of how the JSON Schema Org. updates its specification rather than how others implement or use it. Hence, most users won't be affected as none is bound to provide support for unstable features and implementation docs alongside specification doc will have to be referred to at time of working with it. It is hoped the process described will give both implementors and schema authors the surety of no surprises in their schema processing.
The above can be thought of as analogous with feature supports in browsers.
Further Readings
- https://www.youtube.com/watch?v=GjJpRsVffg0?utm_source=awesome-jsonschema
- https://www.youtube.com/watch?v=ZrVTZwmTR3k
- In OpenTelemetry, specification is split:
https://opentelemetry.io/docs/reference/specification/status/ - https://opentelemetry.io/docs/reference/specification/versioning-and-stability/
- https://json-schema.org/blog