Drop uri-reference format for template URLs

[davishmcclurg]

Server.url and Link.operationRef both allow variable substitution with {brackets}, which means they're not always valid URI references.

For example, the current specification shows
https://{username}.gigantic-server.com:{port}/{basePath} as a Server Object url, but it's not a valid URI reference because the host includes curly brackets.

operationRef similarly includes
https://na2.gigantic-server.com/#/paths/~12.0~1repositories~1{username}/get as an example that isn't valid using the uri-reference format.

I looked into the other uses of uri-reference and they seemed ok.

I'm not sure how to update the actual JSON schemas but readme says to just update the yaml files, so let me know if there's anything else to do.

Related:

• v3.1 Schema bugfix: Update URI fields to use uri-reference or uri where appropriate #2586
• fix: update format for servers.url and links.operationRef in v3.1 schema #3235
• Formally define 3.x URL templating behavior #3256
• OpenApi 3.1 schema validator does not handle variables in server urls davishmcclurg/json_schemer#158

[handrews]

Thanks, @davishmcclurg ! This is more or less a duplicate of #3235, which got a bit bogged down in questions over what format to use (and add to the format registry) for these things.

@MikeRalphson it might be good to go ahead and accept this one to at least stop implementations that try to enforce the existing format from breaking on this. Assuming we can actually work out the logistics of publishing a schema update soon.

[ekzobrain]

This also enables support for IDNs. Current format "uri-reference" does not allow them. If not considering variables, at least "iri-reference" should be used instead.

[handrews]

@ekzobrain OAS 3.x does not have direct IRI support (I am hopeful it will be in OAS 4 "Moonwalk"). IRIs are only supported by being encoded down to URIs.

[handrews]

I think it's worth merging this even though there's another PR that overlaps with it. This one is simpler. Although we still need to solve the schema deployment issues discussed in #151.

[karenetheridge]

Thanks for this! I just ran into this issue when implementing servers url matching in my implementation.

It would be good to see this published so I can make use of it :)

[handrews]

For those following the schema publishing topic who haven't otherwise seen it, I pulled the still-relevant schema publishing challenges out of #151 (which I have now closed) and filed them as #3715 (see also #3716 for related schema development process concerns).