`multipart/related` ambiguity; useless code needed for sync processes returning single output

[jerstlouis]

Describe the bug Implementations are currently required to implement multipart/related to handle execution requests for multiple outputs of the echo process with "response": "raw", even if none of the actual processes can possibly return multiple outputs.

The changes in master for 2.0 obsoletes the need for response and multipart/related completely (see https://github.com/opengeospatial/ogcapi-processes/issues/217), so a significant amount of code to be written to pass the tests is useless (because an implementation may only have processes that return a single output), and would not even be required to conform to 2.0. In 2.0, multipart/related would be negotiated by an Accept: header following OGC API Web Guidelines Principle #10.

The 1.0 standard says in 7.11.4

Not all of these combinations need to be implemented by a server conforming to this standard. For example, if a server only offers processes that support multiple outputs by value, then the server must support multipart/related responses as indicated in Table 11. If, on the other hand, the server only offers processes that support multiple outputs by reference, then the server does not need to support multipart/related responses.

There is a lot of ambiguity in these statements that makes it extremely difficult to know when multipart/related needs to be supported or not:

• servers that offer some processes returning a single output,
• servers that offer processes supporting returning some outputs by values, and others by reference,
• servers including processes that support returning some outputs by value and reference, only by value, only by reference.

Expected behavior The test suite could accept a 501 Not Implemented for the sync / raw multipart/related expected responses to facilitate achieving conformance for simple synchronous execution.

Additional context These are all the tests failing in our implementation because of this Got unexpected status code: 501 on raw / multi output responses expecting multipart/related to be implemented:

• Test Job Creation Default Execution Mode
• Test Job Creation Default Outputs
• Test Job Creation Input Array
• Test Job Creation Input Inline
• Test Job Creation Input Inline Bbox
• Test Job Creation Input Inline Binary
• Test Job Creation Input Inline Mixed
• Test Job Creation Input Inline Object
• Test Job Creation Input Validation
• Test Job Creation Inputs
• Test Job Creation Op
• Test Job Creation Request
• Test Job Creation Sync Raw Mixed Multi
• Test Job Creation Sync Raw Ref
• Test Job Creation Sync Raw Value Multi
• Test Job Creation Sync Raw Value One
• Test Job Op
• Test Job Results
• Test Job Results Sync
• Test Job Success

The following as well, but they should not even be executed because only "sync-execute" is declared for the echo process "jobControlOptions" (we filed issue #40 separately for this):

• Test Job Creation Success Async
• Test Job Results Async Raw Mixed Multi
• Test Job Results Async Raw Ref
• Test Job Results Async Raw Value Multi
• Test Job Results Async Raw Value One

In practice, very few server or client developers are likely to use these multipart/related edge cases. Large or binary raw outputs will either be requested raw as a single input, or by reference in a document response. Multiple small JSON values/objects outputs will be requested within a document response.

[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 (no longer) needed)

[jerstlouis]

We implemented multipart/related to try to better understand what the ETS is doing and make further progress with the test validation.

It is a major pain and source of confusion, and definitely not something that should be expected of implementers. Unlike an application/zip file, it is extremely difficult to get the individual output from a browser response. Chrome wants to save as a .mht (MHTML) which uses that media type, and reports errors on trying to open the file.

Unless we somehow messed up what the multipart/related response should look like, the easiest way I managed to open was to save the response as .eml and open the output in Thunderbird. Two related tests still fail as described in #60, somehow not expecting a multipart/related response for what should be one.

multipart/related is intended for formats where there is one primary part where everything can be seen as a single file, which is not quite the case for multiple processing outputs, where each of the outputs might be usable independently. multipart/mixed is what was used with WCS. All multipart are a major pain for clients, servers and users to deal with and should be avoided if possible. The plan with 2.0 / https://github.com/opengeospatial/ogcapi-processes/issues/217 is to leave it up to content negotiation, with application/zip or application/geopackage+sqlite or application/x-tar as much saner and more practical options for returning multiple outputs.

Ideally, the ETS should either skip or warn rather than fail those no-one-s-going-to-use-it intersection squares of the complex 1.0 table of execution where "multipart/related" lurks.