You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a summary of issues submitted in response to the request for public comments, to be considered to ensure the possibility to define a Workflows extension, as being investigated in the Modular OGC API Workflows project.
In #47 (comment) ), the following general changes have also been suggested:
Inside an input, drop the "input" : { "value" : { part, and directly have e.g. href next to the id. Other properties currently going under input or value (e.g. format when needed) would go at the same level as that.
Rename inlineValue to simply value. When using value, numbers can be directly as numeric values, not strings (e.g. "value" : 0.05) -- it was confirmed that this is already possible.
In addition, to support the new proposed type of inputs identifying an OGC API collection (or a process generating one), a process description document would require an additional mechanism to specify that a particular input is expected to be a collection (and potentially support a particular API such as Features or Coverages). This could potentially be covered in the Workflows extension itself, but we should ensure that there is a mechanism to extend the process descriptoin document to make this possible.
Other additions and relaxed rules for the process execution schema are also being proposed specifically for the Workflows extension.
A draft OpenAPI definition and prototype server for the Modular OGC API Workflows extension is available at:
This is a summary of issues submitted in response to the request for public comments, to be considered to ensure the possibility to define a Workflows extension, as being investigated in the Modular OGC API Workflows project.
These 3 issues have been filed separately:
mimeType
vs.mediaType
: For execution schema 'format', use 'mediaType' rather than 'mimeType' #87uom
andformat
in both ref and inline: OpenAPI literalData only String, inlineValue/referenceValue cannot specify uom / format; Merge complexData and literalData? #95list
input type: Consider alist
input type to accept a list of inputs identified by their own IDs #105In #47 (comment) ), the following general changes have also been suggested:
"input" : { "value" : {
part, and directly have e.g.href
next to theid
. Other properties currently going underinput
orvalue
(e.g.format
when needed) would go at the same level as that.inlineValue
to simplyvalue
. When usingvalue
, numbers can be directly as numeric values, not strings (e.g."value" : 0.05
) -- it was confirmed that this is already possible.In addition, to support the new proposed type of inputs identifying an OGC API collection (or a process generating one), a process description document would require an additional mechanism to specify that a particular input is expected to be a collection (and potentially support a particular API such as Features or Coverages). This could potentially be covered in the Workflows extension itself, but we should ensure that there is a mechanism to extend the process descriptoin document to make this possible.
Other additions and relaxed rules for the process execution schema are also being proposed specifically for the Workflows extension.
A draft OpenAPI definition and prototype server for the Modular OGC API Workflows extension is available at:
https://app.swaggerhub.com/apis/jerstlouis/MOAW/MOAW-0.2
and draft specifications available at:
https://github.com/jerstlouis/wps-rest-binding/tree/master/extensions/workflows
in hope of eventual inclusion in the official OGC API - Processes repository (see also PR #99).
The text was updated successfully, but these errors were encountered: