What about local (filesystem) catalogs? E.g. with a self link of /path/to/my/catalog.json?

Shouldn't that be using the file protocol? file://path/to/my/...?

Most tooling that I've seen won't do that, e.g. pystac.

I'd say then pystac might be generating invalid STAC. The STAC Spec in 1.0 says explicitly "Absolute URL" and /path/to/my/catalog.json is not an absolute URL, it's just an absolute path.

Edit: There is a confusing "if it is available at a public URL" in the item spec, but that sounds like nonsense to me and is not present in the catalog and collection spec. A non absolute self link is useless. But yeah, if we need to cater for absolute paths, then we can pretty much close this PR because there's no reasonable way for us to validate, I think. Checking for a starting "/" won't work on Windows for example. But I think this PR is actually correct and might even remove the "if it is available at a public URL".

@m-mohr I chatted with some folks internally about this, and I think I'm more convinced to be 👎🏼 on requiring a valid URI for href. With the general vibe that STAC is meant to be flexible w/ recommendations for best practice, it was brought up that there might be systems that don't even use protocols, but just use opaque strings as keys to reference other entities. @philvarner put it like this:

... a link href can be any string, but usually it's a URL, locally it can be a file path, and less commonly some other opaque string

Then we need to fix the spec, whick pretty much always talks about URLs, not paths. It's always somewhat contrary to the core STAC princpiles document, which empraces HTTP as core. That might actually require a STAC 2.0 though, because some tooling may now expect URLs (e.g. STAC Browser). @gadomski Needs closer checks and discussion, I guess.

Feelings in the community meeting:
Emmanuel, Francis, Mathias: +1 iri validation
Pete: -0.5 against iri validation