Open Community Working Meeting 2022-07-01

[Relequestual]

Open Community Working Meeting 2022-07-01 - 12:00 PT

Zoom Meeting link: https://postman.zoom.us/j/89562933116?pwd=OWlsQ0RrcDY4S1JQU2d2Q2M0aFFlZz09

Live minutes and notes (gdoc)

Agenda:

Topic	Owner	Decision/NextStep
Review last call's action items	@Relequestual	We should document the current people with permissions and move on from there.
Update from JSON Schema's new Full Time Employee!	@jdesrosiers	Catching up mostly. Will focus on IETF HTTPAPI-WG Mediatypes RFC
Proposing moving alterschema to the json-schema-org organization	@jviotti	Not at this time, but we will keep an eye on developments.
Branch structure and authoring language for the specification repository moving forward	@jdesrosiers	master will be renamed to main, used for future spec development, and any patch releases will be done separately (as ad hoc branches, likely containing the name of the release they patch)
Can we align better around backwards compatibility across releases? Do we want to?	@awwright
What are our high level goals for the next release?	@jdesrosiers

AOB?
If you want to discuss any other business not on the agenda, please add comments during the meeting.
If we do not complete the agenda, your discussion item will likely be rolled over to the next call.

Action items:

• Document JSON Schema team members list as markdown in the community repo #211

Notes:

Agenda Items rolling over:

• list

Recording: link

[jviotti]

We should probably discuss the backwards-compatibility problem and see if we can get closer to agreement?

[jviotti]

Related to that, shall we quickly discuss moving alterschema to the JSON Schema org? I think this ties to the previous point though. If we see alterschema as a potential solution, then it might make sense to maintain it there, and allocate more resources to it. Otherwise, I'll still maintain it myself outside of it for my own use cases!

[Relequestual]

We should probably discuss the backwards-compatibility problem and see if we can get closer to agreement?

Yes, but I'm timeboxing it to 25 minutes, including current summary. Paging @awwright

[Relequestual]

Related to that, shall we quickly discuss moving alterschema to the JSON Schema org? - @jviotti
Yes, sure, let's do that.
Please also create a Discussion in this repo.

[Julian]

Perhaps it's worth even broadening the discussion to "a json-schema-contrib org with more members and lower bars for contributing repos" (or perhaps that's a separate one we could put off).

[Relequestual]

Perhaps it's worth even broadening the discussion to "a json-schema-contrib org with more members and lower bars for contributing repos" (or perhaps that's a separate one we could put off).

I think that's something we would struggle to discuss this with the time we have. I have a lot of opinions about this.
Might be better as a discussion.

[jdesrosiers]

We should probably discuss the backwards-compatibility problem and see if we can get closer to agreement?

I think that might be a bigger discussion that might be best scheduled as separate meeting.

[jdesrosiers]

We should discuss roadmap/goals for next release.

[handrews]

We should probably discuss the backwards-compatibility problem and see if we can get closer to agreement?

Yes, but I'm timeboxing it to 25 minutes, including current summary. Paging @awwright

@Relequestual @jviotti @awwright what I most want to get out of this 25 minutes is an understanding of who is demanding this sort of cross-draft behavior that @awwright is proposing, and what their use cases and expectations are for it.

I have also laid out how I see different eras of features and support across drafts in #192 "Guidance around previous draft support"

[jdesrosiers]

We should talk about converting the spec to something that isn't associated with IETF (probably plain markdown). If we need to convert everything, we should do it sooner than later.

[jdesrosiers]

Let's discuss what approach we want to take for getting draft-next in sync with the 2020-12 patch changes and where we want to continue work (continue on draft-next or work on master)

Also, now is a good time to rename master to main.

[awwright]

I can take a little time to discuss reverse compatibility & interoperability; but what I am looking to propose is if we can come up with a set of "Use cases & requirements":

• What "business functions" should all implementations be able to do, e.g. "assert the value is a string with at least one character" — this would mostly be a representative sample of our test suite
  • Anything that can be processed by a pushdown automata should be required, which is most keywords.
  • What is out of scope — e.g. "verify that this integer is a user ID in my database" is out of scope
• What sort of extensions should JSON Schema support — can I refer to an extension that describes, for example, a MongoDB ObjectId (stringified)?
• ... should it be guaranteed that if the extension cannot be loaded or is not understood, that I can guarantee a result that's not misleading (two different implementations will not produce valid & invalid, respectively? But an error is OK.)
• If there's a technical reason that an implementation cannot implement a keyword (namely: uniqueItems, our usual suspect), that it will not produce a misleading result? (It shall produce an error?)
• How should we support validators that use a lossy JSON parser? (i.e. how do you validate IEEE floats in a cross-platform manner?)
• How should we handle forward compatibility? Can a validator ditch support for all existing schemas once a new draft is published?

... I think we should aim for 100% interoperability, but that may be a lofty goal, so start with some concrete cases that we want to support. Let's start by describing the features we already support and want to keep support for.

These use cases are often published as formal documents, e.g. https://www.w3.org/TR/webrtc-nv-use-cases/

[handrews]

@awwright you are talking about this like we just "come up with" use cases. Unless those align with actual problems, I don't find that process compelling as far as driving further work. They might be compelling in terms of adding new test cases to ensure that any use cases that currently ought to be supported really are, but that's a different thing.

Generally, when we've added complex or significantly different new functionality, it is in response to a well-established problem.

• unevaluated* resolved the multi-year argument over different approaches like $merge or "strict mode" for functionality many had asked for (or assumed incorrectly that additional* already did)
• $vocabulary made extensibility interoperable (or closer to interoperable), which solved the problem of people asking for obscure functionality as keywords because only things in the spec every got implemented in an interoperable way. The approach was validated with the OAS community, with their extensions as a test case, rather than being an abstract offering.
• $recursive* (later $dynamic*) solved the problem that extending meta-schemas was infeasible due to the need to copy-and-paste, which only got worse the more meta-schemas you were trying to work with. And we needed extending meta-schemas to be easy if $vocabulary had any chance of working.
• Splitting $id and $anchor happened in part because $id was a sticking point for OAS compatibility because of $id's complexity and how some things you could do with it (specifically put a JSON Pointer fragment in it) could produce contradictory URIs. Likewise items/additionalItems becoming prefixItems/items, which was another sticking point (OAS previously forbade the array form of items)
• Making $ref a regular applicator keyword in response to the steady stream of people being confused by the replacement of adjacent keywords over the years.

All of these changes were in response to long-established, well-documented problems, and/or were done through engagement with a major consumer of JSON Schema with its own large community.

I don't see anything like that in your list, particularly regarding single schema resources drawing on functionality for multiple drafts. Which seems to be some sort of litmus test for "interoperability" for you, although it's honestly still hard to tell what you're going for there.

I'm not interested in solutions looking for problems. I am interested in actual problems that clearly (to all of us) need solutions. Can you point to well-documented problems in the community that you are trying to address?

Another angle is that many of these problems had workarounds of sorts implemented in the community. $merge and "strict mode" were (and possibly still are) supported by some implementations. Many implementations offered extension capabilities, but they were all different. OAS worked around some of the problems by forbidding certain keywords. That sort of thing. Can you point to where people are working around the problems that you want to solve?

[handrews]

• What sort of extensions should JSON Schema support — can I refer to an extension that describes, for example, a MongoDB ObjectId (stringified)?

I have a very detailed presentation on this that I had hoped to have finished in time for people to watch it before the meeting, but that has not been possible. I hope to have it finished early next week (as a video / slides+script so folks can consume it at their own pace before our next call).

---

• ... should it be guaranteed that if the extension cannot be loaded or is not understood, that I can guarantee a result that's not misleading (two different implementations will not produce valid & invalid, respectively? But an error is OK.)
• If there's a technical reason that an implementation cannot implement a keyword (namely: uniqueItems, our usual suspect), that it will not produce a misleading result? (It shall produce an error?)

Both of these are fully addressed by $vocabulary today. It is frustrating that you are asking us to go back to first principles rather than working with what has already been done, or at least showing some curiosity about it.

---

How should we support validators that use a lossy JSON parser? (i.e. how do you validate IEEE floats in a cross-platform manner?)

We have always focused on the data model. To expand the scope of the project to JSON text would be a radical change.