STAC API - Browseable Specification: Differentiate between API and static

[m-mohr]

As an implementor, it is confusing how to handle the STAC API - Browseable Specification. There's no hint at how a missing conformance class for the "STAC API - Browseable Specification" should be handled and how to distinguish from static STACs which don't have this conformance class.

Some wild assumptions:

• no conformsTo in root landing page -> static catalog -> show child and item links
• stac_version >= 1.0.0-beta.5 and conformsTo present but no browsable conformance class -> API -> don't show child and item links although some might be present?
• stac_version <= 1.0.0-beta.5 and conformsTo present -> API -> ???
• stac_version >= 1.0.0-beta.5 and conformsTo with browsable conformance class present -> API -> show child and item links

Or is it:

• always show available child and item links

Having this in mind, what's the advantage of adding this conformance class to my implementation? I don't really see what it adds to a client such as STAC Browser and how I should handle the different variations in the client.

The only advantage I see right now is that if it is present, in the STAC Index Crawler I can skip the OGC API - Features completely when the conformance class is given.

[philvarner]

I think this is more clear than when you filed this, but I think this speaks to the value of Browseable:

---

A STAC API conforming to the STAC API - Browseable conformance class
(https://api.stacspec.org/v1.0.0-rc.1/browseable) must be structured such that
all Items in the catalog can be accessed by following child and item link relations. This is a more significant
constraint than a STAC API without this conformance class or a STAC Catalog that is available over HTTP but does not
implement STAC API, neither of which have any guarantee regarding the reachability of Items through these link relations. This conformance
class is used to signal to users that they can fully navigate to all available Items using a UI (like STAC Browser,
and also makes it clear to crawlers that they can reach everything by following catalog links.

---

In terms of what to show for a Browse interface, I think this is the decision tree:

• no conformsTo - not a STAC API
  • child + item traversal, if every item isn't reachable then it's not very useful
    - Action: show child and item links
• conformsTo - is a STAC API
  • Children - pageable way to traverse
    • Action: show pages of children results (Catalogs and Collections)
  • Browseable - child + item traversal, will be able to reach every item
    • Action: show child and item links
  • Features
    • Action: heuristic on child + item traversal and /collections/{c_id}/items pagination -- this is hard to figure out, because the catalog could structure these in any way they want
  • Collections
    • Action: heuristic on child + item traversal and maybe showing collections? -- this is hard to figure out, because the catalog could structure these in any way they want
  • otherwise - child + item traversal, but may not be able to reach every item
    • Action: show child and item links