Part 3: cleanup of collection input/output now in core

[fmigneault]

Applies a much needed cleanup of Part 3: Workflows and Chaining.

• Remove "collections" requirement classes since they are now moved in Part 1: Core
• Updates a few updated references and improve cross-references between standards within requirements
• Define missing terms and use them (and align across parts in a consistent format)
• Switch HTTP to HTTPS for requirements and document references

I left the input/output field modifiers since, although partially covered in Core, there are a few patterns (notably properties) that are employed beyond collections, which is only what Core covers.

Updates related to CWL are defined into:

• Part 3: proposal for functional CWL ad-hoc execution with multipart #607

They should technically merge nicely, but a second pass of extra terms/cross-refs could be needed.

FYI @pvretano @jerstlouis

[pvretano]

I'm OK with merging this ...

[jerstlouis]

I need to take a closer look again at Part 1 v2.0 to see what's in there, but wondering whether some of the content here was integrated there? This high-level overview of the use cases was in my opinion quite useful.

The Overview in https://docs.ogc.org/DRAFTS/18-062r3.html#sc_collection_output is quite short.

[bpross-52n]

SWG Meeting from 2026-08-16: Francis will check this again.

[fmigneault]

Beside editorial changes from @pvretano and the removal of Workflow-specific details for Core transition, both Part 1 Collection Output and Part 3 - Collection Output seem to have equivalent contents.

I will wait for feedback of specific elements that could be missing, if any.

[jerstlouis]

Much or all the fields modifiers stuff should already be in Part 1 now, but I forget if there's an option to apply a modifier to the final output of the process or workflow? If using Collection Output, that can be handled at the access mechanism (for the request), but otherwise how it was in Part 3 before is that you could specify these output modifiers at the top-level of the execution request/workflow.

[fmigneault]

From what I can see, it doesn't look like field modifiers are part of collection output in Core. I think is fair since it goes beyond what Core should do. In the case of inputs, the field may be handed-off to the remote API providing the collection, so it makes sense to include the parameters. For collection outputs, we would defer to the generated collection to handle any subsequent field modifiers (since the goal is not do to a workflow inline here).

In other words, once the collection is generated, it is not the concern of Process Core API anymore. As long this collection is ensured to support at least one of the data access mechanism, subsequent requests (with relevant field modifiers as needed) may be sent directly using it.