Thanks a lot for all the extensive discussions and work done to address my concerns in issue #300.
Please take the points raised in this comment as things to consider only if they can be addressed as relatively small editorial-ish changes without a major impact to the publication schedule, and if the SWG agrees that it makes sense to apply these suggestions at this time.
Less contentious:
As previously discussed with @pvretano , Table 2 currently indicates the "Record Collection" Common Component as optional for the "Crawlable" Catalog (Deployment) requirement class. I believe we clarified that it is in fact mandatory, which would be consistent with the "Record Collection" dependency in the Requirement Class table of 9.2.1 - Crawlable Catalog (Deployment).
It might be useful to add "Deployment" in the header of that Table 2 to clarify that "Catalog requirements class" header
More contentious:
Based on that clarification, it becomes clear that the "Record Core" + "Record collection" Common Components, which are used in all 3 deployment types (Crawlable, Searchable aka Records as Features API, Local Resources Catalog), form a Common "Core" requirement class for OGC API - Records. It would greatly simplify things from a reader / implementer perspective to merge Record Core, Record Collection, Crawlable and Local Resources Catalog into one such "Core" requirement class (which it already is in practice, considering that these Common Component requirement classes are all mandatory to implement any of the deployment types, and that the Deployment Type requirement classes do not introduce additional functional requirements).
If we assume this Common Core, and assume that optional requirement classes can be combined with it, we no longer need this confusing distinction between "Common Component" vs. "Deployment Type" requirement class, and we end up with much fewer requirement classes and a much simpler organization.
The "Records API" Common Component and the "Searchable" deployment types are then really one and the same. These two could also be merged as a single requirement class. This merge could also solve the significant confusion that Local Resource Catalogs can also be "Searchable" even if they don't implement what is currently called the "Searchable" requirement class (e.g., we're writing a "Searchable Collections" requirement class in Common).
The "Query Parameters" Common Component and the corresponding requirement classes in Searchable and Local Resources catalog are then also the same. These could just be a single requirement class. It would be a mandatory dependency of "Records API" (but not of Local Resource Catalog)
The "Filtering" Common Component and the corresponding requirement classes in Searchable and Local Resources catalog are then the same. These could just be a single requirement class.
The "Sorting" Common Component and the corresponding requirement classes in Searchable and Local Resources catalog are then the same. These could just be a single requirement class.
The concept of Deployment Types for OGC API - Records still makes sense even if they don't correspond one to-one to a requirement class. The section illustrating these three main catalog deployment types could remain as an informative section (since all the normative content already fits within the merged requirement classes corresponding to the current "Common Components") with examples illustrating the requirement classes needed to implement a particular deployment type, even with this proposed simplification:
Crawlable Catalog Deployment: "Core" (crawlable-only catalogs do not implement any query parameters, even though searchable and local resource catalogs are also technically crawlable)
Searchable Catalog Deployment: "Records as Features API" (Dependency on "Query Parameters" and "Core")
Local Resource Catalog Deployment: "Core" tied to a particular set of local resources (optional support for "Query Parameters")
All catalog deployment types can be extended with "Filtering" and/or "Sorting" (but a "purely crawlable" catalog is not)
Thanks a lot for all the extensive discussions and work done to address my concerns in issue #300.
Please take the points raised in this comment as things to consider only if they can be addressed as relatively small editorial-ish changes without a major impact to the publication schedule, and if the SWG agrees that it makes sense to apply these suggestions at this time.
Less contentious:
More contentious: