This one is the twin to JSON Schema's $schema keyword, and therefore cannot be a uri-reference.

@karenetheridge philosophically I agree with you, but the way the OAS field is written unfortunately allows a relative URI-reference. Of course you'd have to resolve that before you could use it as a dialect URI, and the only way that might work is with a custom dialect, but there's no reason it couldn't work that way.

I do agree that it should have been written as requiring a non-relative URI.

Happy to make the change if needed. Waiting for maintainer to come to an agreement.

@handrews what do you mean "the way the OAS field is written unfortunately allows a relative URI-reference"? What are you referencing here?

@karenetheridge It's the combination of two things:

§4.6.7 states:

Unless specified otherwise, all fields that are URIs MAY be relative references as defined by [RFC3986] Section 4.2.

while the fixed fields description for jsonSchemaDialect says:

The default value for the $schema keyword within Schema Objects contained within this OAS document. This MUST be in the form of a URI.

Strictly speaking, this text allows a URI reference. The value used with $schema of course must be a full URI, but that can be produced by resolving the relative URI-reference normally, just as with any other field that the OAS says "MUST be in the form of a URI". What is used with $schema is the resolved value, not the literal text.

At least that is my interpretation. We can always kick it up to @OAI/tsc for a ruling if you disagree. Again, I prefer your reading (and really dislike that we don't just explicitly say "URI-reference" and instead say "URI means URI-reference unless otherwise stated") but that's what we have to work with.

At the very least we need to tighten up the language that leaves this vague. It is not reasonable to say in one place that a value is a URI, and then at the top say "actually that means URI-reference" because now there's no way to say that no, really, this actually has to be a fully-resolved URI.

Also, in any place where we do allow a URI-reference, we should be explicit as to how that value will be resolved -- whether it's against the URI used to identify the entry document, the current document, or the Host header on the current HTTP request under consideration (when relevant) -- I can see places where each of these might be the appropriate choice for URI resolution.

@karenetheridge take a look at the XML Object's namespace field for how we say a field is a fully-resolve URI (again, I agree we should use the correct terminology per RFC3986 and not what we're doing now, but we do have ways to say we don't want a non-relative reference). We are very explicit about how OAD URI-referencess and API URL-references are resolved. Each of those topics gets a full section in the 3.1 specification. In any event, this is drifting outside of the scope of this PR and should continue in a discussion or issue.