Extensible jobControlOptions for Processes - Part 3

[jerstlouis]

Describe the bug
Currently, extending the jobControlOptions with a value not specified in jobControlOptons.yaml results in a test failure. There is a plan to add a new value for the OGC API - Processes - Part 3: Workflows & Chaining "Collection Output" requirements class. The value will likely be "collection-output", possibly "landing-page-output" as well.

Expected behavior
There should be a mechanism to extend the jobControlOptions (possibly the schema could have been a oneOf with any string or an enum string), or at least some provision to allow implementing Part 3 "Collection Output" while avertising support for this execution mode (?response=collection / ?response=landingPage), while conforming to Part 1: Core.

One alternative might be to extend outputDescription.yaml, but this execution mode really is neither sync nor async excution.

Currently our implementation includes workflow-collection, and this fails for Test Process List Success with:

body.processes.9.jobControlOptions.1: Value 'workflow-collection' is not defined in the schema. (code: 1006)
From: body.processes.9.<items>.<processSummary.yaml>.<allOf>.jobControlOptions.1.<items>.<jobControlOptions.yaml>.<enum>

We will likely change this to collection-output, and add landing-page-output once supported as well, and update Part 3 to reflect this if it makes sense.

cc @pcdion @gfenoy @pvretano

[jerstlouis]

Our latest Processes conformance test is now integrated and this failure can be tested directly from https://maps.gnosis.earth/ogcapi (Gerald's workaround is needed).

I have updated to use collection-output in the jobControlOptions.

EDIT: I have since removed the collection-output to avoid the TEAM engine errors until this has been addressed.

[ghobona]

We are planning to set up separate ets repositories for extension parts of OGC API Standards.

Therefore, Part 3 will have its own ETS and work on the ETS will only start when the standard is approved.

Consequently, this GitHub Issue is now labelled on-hold until it is moved to a new GitHub repository for OGC API - Processes - Part 3.

[jerstlouis]

We are planning to set up separate ets repositories for extension parts of OGC API Standards.
Therefore, Part 3 will have its own ETS and work on the ETS will only start when the standard is approved.

But the parts merely defined additional requirements classes to the existing standard, which normally would require all of the core to exercise these extensions. So I'm not sure wether a completely separate ETS is really the best approach.

The heart of this issue is that an implementation should be able to pass both the "Core" ETS as well as the "extension" ETS, regardless of how the ETSs are the same or separate.

This issue is about the extensibility of OGC API standards in general (how to test extensible enums), something that can be considered before the work on the Part ETS starts.