Relative -> absolute links for stac-spec references

[duckontheweb]

Related Issue(s): #
#114

Proposed Changes:

1. Use absolute instead of relative links for all references to pages in the radiantearth/stac-spec repo.
   All URLs are pinned to v1.0.0-rc.1.

PR Checklist:

• This PR is made against the dev branch (all proposed changes except releases should be against dev, not master).
• This PR has no breaking changes.
• I have added my changes to the CHANGELOG or a CHANGELOG entry is not required.

[matthewhanson]

@duckontheweb we've been linking to the master branch of the stac-spec from the extensions, rather than to the v1.0.0-rc.1 tag. It saves us from having to update the links (which once we get to 1.0.0 should be an uncommon occurrence), but there's also a risk that links could become broken.

For now, I think linking to master branch is probably best. thoughts @cholmes ?

[cholmes]

I'm definitely of two minds on this. I do think the rc.1 link is less good, because it's going to be rc.2 soon and then 1.0.0.

But I don't love going straight to master, since if stac spec were to go to 2.0 and then someone was looking at STAC API release 1.0.0 they'd follow a link there, which isn't really what STAC API is based on.

I think best may be to do 'master' for right now, but once STAC 1.0.0 is at then we could change it to link there...

[duckontheweb]

Yeah, I'm a little back-and-forth on this, too. It's not hard to update the stac-spec version in these links, so pinning to a specific version seemed like an easy way to make sure they don't break. On the other hand, this version of the API spec doesn't really "depend" on the content of v1.0.0-rc.1 of stac-spec in any specific way that I can see, it only depends on the fact that files stay in the same place within that repo, so maybe pointing to master is fine and we just know that if we change the structure of that repo then we need to update these links as well.

[duckontheweb]

@matthewhanson @cholmes I updated the links to point to master instead of 1.0.0-rc.1

[m-mohr]

Why not just update the submodule?

[duckontheweb]

@m-mohr See #114 for the reasoning behind this. Relative links to a submodule do not work correctly on GitHub since the directory doesn't actually exist in that location.

[cholmes]

@duckontheweb - are you able to update this PR so it uses a sub-tree? Or would that need to be a new PR? Or some other way to get that working?

[duckontheweb]

I opened #119 and marked it as WIP until we confirmed that's the way we wanted to go.

[duckontheweb]

Closed via #119