Repository navigation
Open TSC Meeting, Thursday 07 January 2021 #2433
Description
NOTE: This meeting is on Thursday at 9am - 10am PT
Zoom Meeting link: https://zoom.us/j/975841675. Dial-in passcode: 763054
In order to give some more visibility into the topics we cover in the TSC meetings here is the planned agenda for the next meeting. Hopefully this will allow people to plan to attend meetings for topics that they have an interest in. And for folks who cannot attend they can comment on this issue prior to the meeting. Feel free to suggest other potential agenda topics.
Please submit comments below for topics or proposals that you wish to present in the TSC meeting
| Topic | Owner | Decision/NextStep |
|---|---|---|
| Discuss linking to JSON Schema Draft 2020-12 / IETF links | @MikeRalphson | Change links to point to IETF draft |
| Should we publish a schemaObject only metaschema for backwards compat with OAS 3.0 ? Or can we use a fragment id? | @MikeRalphson | Ben to provide feedback |
| Use of GitHub discussions? | @MikeRalphson | Done |
| Reference Object clarification PR #2435 | Darrel | |
| Release planning | @webron | |
| PR on Content Type Schemas #2351 | ||
| AOB (see below) | TDC | |
| New issues / PRs labelled review | @OAI/triage | |
| New issues without response yet | @OAI/triage |
/cc @OAI/tsc Please suggest items for inclusion
Activity
Relequestual commentedon Jan 7, 2021
https://tools.ietf.org/html/draft-bhutton-json-schema-00#section-8.2.1
No fragments in
$idvalues.We left in "SHOULD NOT contain an empty fragment" for slightly nicer permissible backwards compatibility.
MikeRalphson commentedon Jan 7, 2021
@Relequestual thanks - just for clarity, this would be the value of a
$schemakeyword, not a$id- does the same hold true there? I can't see similar wording in s.8.1.1karenetheridge commentedon Jan 7, 2021
my $0.02: the
$schemavalue SHOULD exactly match the value of the metaschema's$idkeyword, as implementations frequently cache metaschemas in memory and use that$idstring as the hash key. so if you're going to add a trailing#where one didn't exist in the$idas well, you might be in for a world of hurt.as to whether a
$schemacan have a (non-empty) fragment... I think that's legal, as the spec doesn't (currently) require that this uri be the canonical uri of a schema, but I think that's something we should probably add.summary: a future version of the JSON Schema spec might very well prohibit empty fragments for both
$idand$schema, and require$schemaURIs to be the resource's canonical URI. so it would be wise to not encourage otherwise in the meantime, and OpenAPI should avoid the use of empty fragments (i.e. trailing#in URIs) in all of its documents.Relequestual commentedon Jan 7, 2021
For clarity, I'm pretty confident that we will prohibit even empty fragments for the 2021 drafts.
mehdijalaly commentedon Aug 20, 2022
#2433 (comment)