Consider new meta-schema for the proposed "patch" draft after 2019-09

[handrews]

I think we should consider doing the next draft as 2020-03 or 2020-04, and align it with OAS 3.1. Reasons for doing so include:

• Hardly anyone has implemented 2019-09, and anyone who has it in progress could just that roll over to 2020-03. We could provide guidance that supporting 2019-09 separately from 2020-03 is not necessary (or even desirable).
• 2020-03 will be six months, the typical expected length of time for a new IETF draft, so it won't be a case of fast thrashing like the one-month-later bugfix we did for draft-07.
• Split "unevaluated*" into separate vocab for separate support indications #853 about splitting unevaluated* into its own vocabulary for managing implementation requirements would make things more clear and definitely require a meta-schema change
  • Alternatively, if we want to make unevaluated* fully required, that would arguably be a change in semantic expectation and therefore a new vocab URI and new meta-schema URI.
• Some of the schema loading information including Allow different $schema values in same document if different resources #850 is technically a real change, even if not one that shows up in the meta-schema.
  • On a related note, rearranging the section as proposed in Consolidate information on loading schemas #849 will cause bookmarks to the https://json-schema.org/2019-09/*.html documents to break.
• Email syntax should be based on RFC 5321 (not RFC 5322) #852 (changing the RFC for email syntax) seems worth considering, and would technically be a change in behavior, although again not one that would show up in the meta-schema
• "unevaluatedItems" should consider "contains" #810 (unevaluatedItems and contains) might be considered significant enough to be confusing to change within the same meta-schema. TBH, I find that issue confusing in general which is kind of ironic.
• Looking over the list, there are lots of little changes that aren't meta-schema-ish, but do feel like they add up
• With the increased focus on Schema Resources and the clarity that brings, I could see reviving metaschema does not prevent $schema from appearing in subschemas #748 about using the meta-schema to forbid $schema in subschemas. And we could throw in $id and $recursiveAnchor as well.
• Talking with various people about adding extension vocabularies, I think we should revisit Should unknown keywords be collected as annotations? #698 (collecting unknown keywords as annotations by default). This is the most likely common extension use case and would provide a useful default that is compatible with "ignoring" from the point of view of validation. But it is arguably a notable change.

OK that's more than enough for now. Thoughts?

We could also align the test suite with 2020-03 (or 2020-04, whatever) and try to put them out at the same time, and just not have a specific 2019-09 suite, which would further make clear that 2020-03 is where the focus is.

[handrews]

@webron @darrelmiller @earth2marsh @MikeRalphson @whitlockjc I don't think anything in here would require significant new considerations, although I'm happy to walk anyone through it on a dedicated call or during the TSC meeting, assuming other JSON Schema folks think this is the right move for the next draft.

All of these are geared towards improving clarity and filling in under-specified areas. Particularly those around the "Schema Resource" concept which was a bit of a last-minute idea and (as @webron knows) isn't quite consistently used throughout the spec. All of this stuff is fairly straightforward, so we should be able to coordinate schedules.

No matter what, I want the next draft to align with OAS 3.1 and take care of any clarifications or tweaks needed to get everyone comfortable with it. That alignment is more important to me than any particular issue set here.

[Julian]

Seems like a long enough list to me that a new metaschema makes sense.

[Relequestual]

I'm in favour of this, and simply not having a 2019-09 test suite.
We could EVEN put in the folder with a readme... GOTO: 2020-03 (or whatever it ends up beign)

[whitlockjc]

👍

[handrews]

@Relequestual yeah I think that GOTO: 2020-03 is what we should do.

We can talk about how the point right now is not for every validator to support every draft, but to guide implementors towards the most useful recent draft, or something like that.

[Relequestual]

@handrews what's the requirement to close this out?
Are we waiting on one or two from OAS to confirm?
If we confirm, I assume that means a new issue for this milestone to

• update meta-schema
• check references to draft name

[handrews]

@Relequestual we've got 2 OAS TSC members with thumbs-up, I just want to get confirmation from @webron.

Yes, those would be the two steps. Or rather, "check references to meta-schema name" (draft name could just as easily refer to <name>-json-schema-<nn>).

[webron]

Since I'm late to the game, figured I'd add a comment and not just a reaction: 👍.

[Relequestual]

OK, we have ageed this is the way forward.
What's the required action for conclusion of this issue? (Create more issues / rename this issue?)

[gregsdennis]

I'm happy with this. I know how to handle in my library since I've already implemented 2019-09.

[handrews]

@Relequestual I'm kind of using the issues as an informal checklist as it covered some things that weren't already in the milestone. I'll make sure everything's filed and then close it.

[handrews]

At this point this is well-established as a "yes" answer, and everything else above that I wanted to track has been filed. No need to keep this open given that releasing a meta-schema is a normal part of the process.