Refactor hard-to-maintain lists

[m-mohr]

In the best practices we have lists of relation types, media types etc. With the slow release cycle of the main spec, this is getting outdated quickly and it's relatively hard to maintain the list. I'd propose to clean-up the list and maintain it separately. For example, the list of relation types seems for some still relatively "unmature" (origin seems to be the card4l extension), but we list them regardless in the main spec, which is weird.

Similarly, I'd propose to remove the list of stable extensions from the extensions page and instead just link to stac-extensions.github.io.

[cboettig]

👍 Thanks @m-mohr !

Would love to see a more extensive, probably crowd-sourced list of what people are using for media types for different assets. https://github.com/radiantearth/stac-spec/blob/master/best-practices.md#common-media-types-in-stac is a nice start but obviously hardly scratches the surface of types.

Meanwhile, are their any guidelines for winging this? I'm not hopeful that we'll ever get registered MIME types for most of these (how long have we been waiting for parquet to get a MIME type??) I'm currently trying to document some vector objects that use flatgeobuf, and ESRI's shapefile and geodatabase formats; wondering if the GDAL driver names might provide a reasonable basis of reference: https://gdal.org/drivers/vector/index.html , e.g. application/x-<DRIVER SHORT NAME> maybe?

Or maybe that's a fools errand and we're better off omitting the type field and just providing a human-readable explanation of the file format using title or description fields?

[m-mohr]

I've moved your issue to #1295 @cboettig
It seems somewhat different from the general refactoring, which is not really meant to change contents at this point.
But it seems valuable to discuss your points so moved them into a separate issue to better keep track.

This issue schould probably be worked on once most other PRs have been merged.,