jerstlouis
commented
1 month ago @fmigneault I don't see a conflict there, but the current "prerequisites" are not reflected as intended.
It definitely is the intent that OGC API - Feature is an access mechanism for the collection output/input.
Regarding the sub-requirements for input field modifiers (which is a particular requirement class that an implementation can conform to or not), there is a plan to potentially define that as well in Features as a conformance class of Part 6 (see https://github.com/opengeospatial/ogcapi-features/issues/927).
Similarly, the Collection Output has prerequisites that enforce support of all OGC API data access mechanisms:
The Prerequisites there are wrong. There should be a "one of" the "Core" requirement class of the different access mechanisms, plus a bunch of optional dependencies.
Same thing for the Nested Process. There should only be a dependency on Part -1 Core, + an "optional" dependency on the others (to indicate that these capabilities also work with Nested Processes).
I believe there may actually be a note in the source ASCIIDoc at the moment that does not get reflected in the HTML / PDF output. We should look into fixing that. Thanks!
fmigneault
In https://docs.ogc.org/DRAFTS/21-009.html, most definitions indicate something in the form or (emphasis mine):
This implies that providing a collection as, for example, ONLY an OGC API Features (or STAC) endpoint would be valid. However, that API does not necessarily handle all sub-requirements for input field modifiers. For example,
filterandsortBycould be handled relatively easily in this case, but notproperties, since it involves a more advanced set of capabilities to compute derived values.Similarly, the Collection Output has prerequisites that enforce support of all OGC API data access mechanisms:
https://docs.ogc.org/DRAFTS/21-009.html#_requirement_class_collection_output
Another example is the Nested Processes, which requires: http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/nested-processes
However, if a nested process happens to return a GeoTiff, for example, and the parent process in the chain receiving it supports this media-type, there is no reason to go through Collection Input, Remote Collection, or apply any Input/Output Fields Modifiers. A Nested Process definition would be valid on its own. Although these capabilities could be combined simultaneously with a nested process that returns a collection output applied for a particular processing chain, they are not required.
I believe it would much more beneficial for the adoption of these capabilities to reduce the "combined set" of requirements. They define much more granular combinations. This would allow implementers to gradually add more support, without having to implement everything all at once, especially that not all capabilities are necessarily desired. It would also better align with the mention of "at least one" OGC API data access mechanism that must be supported, not all of them.