Revisit URL verbiage in Source Descriptions

[frankkilcommins]

From @handrews review feedback.

The spec defines:

A URL to a source description to be used by a Workflow. MUST be in the form of a URL. MAY be defined using relative references as defined by RFC3986.

Referencing WHATWG here is problematically inconsistent with OAS 3.x. If you must reference WHATWG (a decision with which I rather disagree, because that spec is insanely hard to interpret unless you're writing a parser exactly the way they want you to, although I understand perhaps I'm too late with this feedback), "URL" is not the correct term as it is defined in terms of in-memory structs. The correct term would be "URL String". I'm still doubtful that WHATWG's "URL String" and RFC 3986 are entirely compatible, and that strikes me as a problem given that RFC 3986 is used everywhere else in the OpenAPI world. And you're even mixing WHATWG's "URL" definition with RFC 3986's relative reference resolution process, which is not necessarily identical to WHATWG's relative resolution process (I haven't really checked that part, though).

Since WHATWG's URL spec is a "Living Specification", this requirement may effectively change without notice, further introducing interoperability problems. "Living specifications" are a radically different model than how OpenAPI specs work.

If the desire here is purely to ensure that the URL is resolvable in accordance with its scheme, you can just say that along with referencing RFC 3986. I strongly believe that OpenAPI as a whole, across all of its specifications, should consistently use either IETF RFCs 3986/3987/6874 or WHATWG, and not mix the two. Preferably the IETF RFCs as that is what is already established.

With most URI/URL-related libraries you're lucky if you can find one that properly conforms to any specification. Finding one that will conform to WHATWG for some things and RFC 3986 for others is almost certainly impossible. Except perhaps by coincidence.

Also, you probably want an "and" between "URL," and "MAY be defined...".