Open TSC Meeting, Thursday 07 January 2021

[MikeRalphson]

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

[Relequestual]

https://tools.ietf.org/html/draft-bhutton-json-schema-00#section-8.2.1

If present, the value for this keyword MUST be a string, and MUST
represent a valid URI-reference [RFC3986]. This URI-reference SHOULD
be normalized, and MUST resolve to an absolute-URI [RFC3986] (without
a fragment). Therefore, "$id" MUST NOT contain a non-empty fragment,
and SHOULD NOT contain an empty fragment.

No fragments in $id values.
We left in "SHOULD NOT contain an empty fragment" for slightly nicer permissible backwards compatibility.

[MikeRalphson]

@Relequestual thanks - just for clarity, this would be the value of a $schema keyword, not a $id - does the same hold true there? I can't see similar wording in s.8.1.1

[karenetheridge]

does the same hold true there

my $0.02: the $schema value SHOULD exactly match the value of the metaschema's $id keyword, as implementations frequently cache metaschemas in memory and use that $id string as the hash key. so if you're going to add a trailing # where one didn't exist in the $id as well, you might be in for a world of hurt.

as to whether a $schema can 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 $id and $schema, and require $schema URIs 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]

For clarity, I'm pretty confident that we will prohibit even empty fragments for the 2021 drafts.

[mehdijalaly]

#2433 (comment)