-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add minOccurs and maxOccurs to output description #414
Comments
Might be related to #412. |
If the output definition is a schema defined as an array of 1 or more elements, with a description that says there will be as many elements in that array as occurences of that input, I don't think this breaks anything -- the schema does define one output: an array of multiple elements making up the single output instance.
Having a results.yaml response at this end-point would introduce so much additional confusion, because results.yaml is used for Things remain much simpler if it is only used there, because normally But if one wants to do something like you describe, then one could simply define a JSON schema for the output that's similar to results.yaml with links to individual outputs? (the links could probably even be to Other potential alternative way to handle such use cases:
|
@jerstlouis so much confusion? Really? The basic rule still applies just clarified a little bit. If you are GET'ing a single output VALUE then you get the bare value subject to content negotiation. Otherwise you get Seperate execution is not a solution to this problem. The outputs may or may not be correlated to the inputs. I was trying to provide a simple uncorrelated example but we have a process from a client that takes N inputs and generates M outputs where M!=N. Part 3 seems like an overly complex solution to a simple problem. Besides, these deployed processes are not created by us and so we may have no control over how the outputs are generated or put into and OGC collection or even if the creator of the process want the data to be presented and/or accesses that way. |
SWG meeting from 2024-05-27: @pvretano will create a PR for us to check the ramifications. |
I think this might cause issues for KVP execution. A request is allowed to indicate However, a corresponding outputs definition would not work, as they need to be accessible by the specific ID under I am curious about the use case of the process that takes I tend to agree with @jerstlouis on this. I believe this case might be better addressed with some alternate multi-request handling or an alternate process output definition. I believe that |
@fmigneault I don't understand which ambiguity you are refering to ...
|
Let say If you have a process that has at the same time:
Arrays in For a client, interpreting these combinations becomes very complicated quickly. I find we are not considering the more complicated use cases, and are potentially recreating/increasing the (already complicated) considerations about inputs where these kinds of issues were mentioned time and time again. |
@fmigneault if . For outputs 1,2,3 and 4 you can use the |
That makes sense. What I foresee becoming an issue is regarding
That would be a great way to handle it. It would allow a clear distinction between a multi-output array and a single-output that happens to be an array. Ideally, there would be a way to infer this directly from the JSON responses on |
Right now, the specification makes the assumption that the correlation between a named output and an output value is 1:1. However, I've run into use cases where it would be convenient to allow the correlation to be 1:N or some other ratio. I'm thinking of a simple use case where you have a process that has a single input with
minOccurs=1
andmaxOccurs=unbounded
and generates a single output ... but you want one output value for each specified input.Right now the only way I can see this being described is using the
schema
element with an array but that kinda breaks the "the scheme describes a single instance value" rule that applies to inputs.Adding
minOccurs
andmaxOccurs
to the output description and extending the results path to/jobs/{jobId}/results/{outputID}/[N]
where N is the Nth output value that corresponds to the Nth input value would allow a more symetrical description on inputs and outputs.The same rules would apply to fetching a single output or multiple outputs that currently apply. If you
GET /jobs/{jobId}/results/{outputID|
you get a results.yaml with all the output values. If you fetch/jobs/{jobId}/results/{outputID}/[N]
you get the content-negotiated output as you currently do. The defaults would be set to be backward compatible.The text was updated successfully, but these errors were encountered: