outputTransmission and jobControlOptions not clearly explained
m-mohr opened this issue · comments
I'm pretty much reading OGC API Processes - Part 1 for the first time in detail.
I found outputTransmission
and jobControlOptions
in the specification accompanied by a schema.
Unfortuantely, it is not clearly explained what these fields what they are for (or I missed it).
Also it seems the enum values defined in the JSON Schema are not explained.
@m-mohr I think these are gone in the next version but ...
jobControlOptions
is used to indicate whether you want to execute a process synchronously or asynchronously or ... actually I don't recall whatdismiss
is supposed to do here since there is a Dismiss conformance class for deleting a job.outputTransmission
is supposed to control whether the server responds, as a result of processing, directly with the response value or whether the server responds by reference (i.e. the server caches the response value and provides a link that you can use to retrieve the value).
NOTE: When I say "value" here I mean the results of processing. That could be a GeoTIFF ... for example.
As I said, both these parameters are gone in the next version replaced instead with the Prefer HTTP header (and accompanying parameter).
@m-mohr @pvretano Although outputTransmission
might be gone in the next version, I believe jobControlOptions
remains as the way to tell whether a particular process can be executed synchronously and/or asynchronously.
The dismiss
here might be saying that a specific process can be dismissed, whether those without may not?
It would be good if we could link to an auto-generated draft of Processes - Part 1: Core 2.0.
Indeed. They are not gone completely (nor should be), but rather replaced by the Prefer
header approach.
21-AUG-2023: jobControlOptions
is still used in the process description to indicate whether a process can be executed synchronously, asynchronously or both. Executing a processes sync or async is indicated using the Prefer
header. The outputTransmission
parameter is still in the processes description but should not be as it is no longer used. This is likely an artifact left over from when we migrated to the new schemas. @pvretano will verify and remove it if necessary and then close this issue via a PR.