Open Community Working Meeting 2022-08-01

[Relequestual]

📺 See Recording

📎 Attached Doc

⏪ Go To Previous Meeting

Agenda

Topic	Owner	Decision/NextSteps
Review last call's action items	@Relequestual	Last call's action items were reviewed
Presentation on forwards compatibility & designing for continuous evolution	@awwright	The presentation was given and members asked for examples and further details regarding the same
Media type registration update and status	@jdesrosiers	Follow the discussion #198
JSON Schema glossary page or site	@Julian	Follow the discussion json-schema-org/website#266
How to deprecate old versions	@gregsdennis	Follow the discussion #192

Highlights

• Some agenda items were rolled over

• Media-type work discussed

• Compatibility and designing for continuous evolution

Actions

• Create a JSON Schema Glossary Page or Site. See discussion json-schema-org/website#266

• How to deprecate old versions. See discussion #192

• @awwright to share examples and further details on compatibility considerations. Read here

• @handrews to add his comments regarding media-type work

• Check in with @jviotti regarding CI work

Attendees

Account
@Relequestual
@awwright
@jdesrosiers
@Julian
@gregsdennis
@handrews

Details

Media-type work

Updates shared by @jdesrosiers regarding media-type work.

• @handrews brought up the lack of bootstrapping problems
• @jdesrosiers we have current and previous considerations to cater to.
• @handrews asked for more time to think and chat about media-type work
• @jdesrosiers proposed registering the media type defined in the spec for now/current, and consider a new registration when we have fixed outstanding issues/challenges

---

Presentation regarding compatibility considerations

Compatibility presentation by @awwright. Some highlights from the presentation and member's comments are presented below.

• New servers should be compatibile with old client and vice versa. i.e old schemas should be compatibile with new validators and vice versa.
• No change to keywords behavior, scope of keyword should not reduce.
• @handrews and @jdesrosiers acknowledge that there are issues with unknown keywords becoming keywords.
• Incremental addition of keyword and additional meta-schemas, that allows for compatibility.
• Regarding enabling evolution:
  • Defined responses should not shrink or grow
  • Defined request may grow in areas where answers and non-answers can be distinguished
  • Language space larger than behavior thereby allowing for evolution.

---

[awwright]

I have a short presentation on forwards compatibility & designing a protocol for continuous evolution.

[jviotti]

Sounds exciting!

[awwright]

Thanks for questions everyone. I presented a work-in-progress, so to clarify what the goal is:

Consider my example that showed the behavior for "draft-3":

Request	Response
objects whose validation keywords are valid	✔️❌
objects with an invalid validation keyword	⁉️
non-objects	⁉️

This has very few options for forward compatibility, and none that permit defining a new property name. That is, the only way to add keywords is in a new release of JSON Schema is to do so in a way that "overlaps" with the behavior of previous specifications—depending on if you're using draft-3 or draft-4, you will get different answers.

What I'm going to spend this week doing is filling out this table for the all the other versions of JSON Schema.

This can help determine what overlapping behaviors we have, and where there's "over-allocated' behavior (behavior that looks like an answer, but isn't used by clients); and with this list of overlapping behaviors, I can craft examples, and we can debate how to resolve the ambiguity.

Importantly, this technique applies to $schema and $vocabulary; we can determine exactly where the specifications have defined contradictory behavior, and make a decision how to handle it.

[awwright]

Resolving the ambiguities will involve adding conditions that further constrains when a behavior may be used. For example, adding a condition "if $schema mentions draft-3, then use the old behavior; else use the new behavior."

Or maybe even removing some old behavior altogether. For example, draft-02 did not define "required". But it's unlikely that any schema used "required" and expected it to be ignored; therefore, the behavior where "required" is ignored can simply be removed, and this would resolve the ambiguity.

[benjagm]

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