Explicit support for Relative Traversal (Deep Nesting) on any Resource

[jonhealy1]

I've been evaluating the Children extension for use in deeply nested archives. Because the spec strictly limits responses to immediate children, I believe we need to explicitly standardize Relative Traversal to avoid navigational dead ends.

The File System Analogy

The current design feels incomplete when compared to standard File System semantics.

• In a File System: If I run ls / and see a directory called photos, I implicitly know I can run ls /photos to see what is inside. The "List Children" operation is valid on any container.
• In this Extension: The spec defines GET /children (equivalent to ls /), but fails to define the equivalent of ls /sub-directory.

Without this definition, the API acts like a file system that only allows listing the root directory, making sub-directories "black boxes" that cannot be browsed.

The Context

The Overview explicitly states:

"The purpose of this endpoint is to present a single resource from which clients can retrieve the immediate children of a Catalog"

However, the Example JSON shows a sub-catalog (cool-data).
This creates a traversal gap:

1. The Dead End: I can see cool-data exists in the root list. But if cool-data has its own children, I have no standard way to list them.
2. The Missing Link: A generic client cannot assume it can append /children to the sub-catalog's URL because the spec doesn't define that pattern.

The Proposal

The spec should explicitly standardize the pattern of appending /children to any valid Catalog or Collection ID to retrieve its immediate descendants.

For example, a client should be able to construct these URLs to traverse the graph recursively:

• GET /catalogs/{id}/children
• GET /collections/{id}/children (if the collection contains sub-collections)

Why this is necessary

This formalizes the "Graph Traversal" pattern. It allows generic clients to build file-browser-style interfaces that can navigate infinite depth simply by appending /children to the current node's URL, exactly as they would in a standard file system.

[m-mohr]

That's my understanding of how the extension should work. It mentions the landing page in a couple of cases, which should only be a (prominent) example IMHO.

If we just define GET /children, it only solves the "traversability" problem for the first level, which is not super helpful. I also think that this extension should allow the same functionality for any depth, otherwise it is not really helpful.

[jonhealy1]

I guess the extension documentation should explicitly state this.

[m-mohr]

With regards to a /children/{id} endpoint, I think the intention here was to leave this open. Following the hypermedia approach that we use in STAC, you can determine the location by the self link in the catalogs that are listed in /children. If a provider wants to implement GET /children/{id} it doesn't restrict this, you are open to implement it, but it also offers users a way to have a different structure, which I think is fair and useful.