Execution endpoint input specification should be separate conformance class?
jkeifer opened this issue · comments
I know our implementation is probably designed a bit differently than a "normal" OGC Processes implementation, but we've run into a bit of a hiccup getting conformance with core due to the complexity specifying inputs when executing a workflow.
For us, we are currently passing a single input into all our processes that is always a json object, more specifically a STAC item collection. We currently have no use for and do not currently want to support things like passing inputs by reference, as we effectively always get the inputs by reference because they are STAC (well, they're not always valid STAC (like when a STAC item hasn't ever existed and we are trying to make one), but we say the inputs will always be "STAC-like" and require the use of references to an underlying data assets like STAC). And we don't need to have single value parameters either--anything like that is also embedded in our json payload format.
So we end up passing this input as a qualified input value in all cases, which works of course. But it means that we only need to support that one branch of all the several ways the spec supports specifying inputs, and we don't want to add code we won't use and don't want to support just to get full conformance with the spec.
This latter point suggests to me that perhaps this input specification part of the core conformance class is not actually "core"--and thus I wanted to see if there might be interest in considering the idea of splitting it out into a separate conformance class or set of classes. Maybe there'd be a different conformance class for input values vs references vs qualified inputs?
13-NOV-2023: Discussed changing the specification to allow a server to declare, on a per-input case whether the input can be passed by value or by reference. This would alleviate servers having to support both as is a requirement right now.