Should OpenAPI highlight the possibility of using the data URL scheme for external examples?

[hudlow]

Originally raised here: https://github.com/OAI/OpenAPI-Specification/pull/4647/files#r2135992019

My baseline assumption is that the data-URL-scheme is already perfectly valid as a URI for externalValue in an Example Object. As far as I know we don't enumerate valid URL schemes that could be used in a URI, so there are plenty of schemes that are valid as far as OpenAPI is concerned but probably not resolvable by most tooling. (Without getting into the broader question of when you can treat a URI as a URL...)

For example, I assume ftp://example.com/foo.png is a perfectly valid URI for an externalValue but not something most tools would attempt to resolve.

What I'd like to resolve here is:

1. Am I right that this is already valid?
2. If we think this is useful and not an anti-pattern should we add examples showing its usage and its utility?
3. Should we go out of our way to suggest that tooling (in... 3.??) ought to be able to resolve data URLs in some way?

Something like:

externalValue: "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAIAAAACCAIAAAD91JpzAAAABGdBTUEAALGPC_xhBQAAADhlWElmTU0AKgAAAAgAAYdpAAQAAAABAAAAGgAAAAAAAqACAAQAAAABAAAAAqADAAQAAAABAAAAAgAAAADO0J6QAAAAEElEQVQIHWP8zwACTGCSAQANHQEDqtPptQAAAABJRU5ErkJggg%3D%3D"`

[handrews]

There's nothing stopping implementations from supporting this, but there is kind-of an implicit assumption that http, https, and (perhaps impliclty) file URI schemes are all that need to be supported.

In truth, for most URI schemes that might be used in referencing, the separation of location and identity means that it's just a question of locating the matching URI in $self or $id. So as long as you support those fields/keywords and treat their URI values as opaque, URI schemes like urn or tag will work just fine.

But data requires actually parsing the data out of the URL (URI? URL? I guess it's a locator as it "locates" the target within the URL syntax itself?).

The trade-off of requiring data support is not clear to me, but there's definitely value that comes with whatever the cost is. And there are libraries implementing data support out there.