Support of transactional extension
christophenoel opened this issue · comments
I have added the schemas for the transactional operation deploy / undeploy
7bdee9d
Work on a Transactions extension has started at https://github.com/opengeospatial/wps-rest-binding/tree/master/extensions/transactions/standard
Some change requests and ideas:
- Class Transactions: (personal note) --> I would prefer that at least the body of the POST request comply to the OGC Application Package (which is still generic enough !)
- Class Transactions: "The body of the POST request shall contain a formal description of the process to be dynamically added to the API." --> maybe a disambiguation with "process description" would help. Suggestion: "The body of the POST request shall contain an application package, i.e. all resources needed to get an executable of the process and the information needed to describe and invoke the execution of the process to be dynamically added to the API."
-
- Class Transactions: suggested to add: "The body of the POST request shall comply to the deployment profile classes advertised in the conformance classes document"
- Class Transactions: "A server may support any processes description encoding in the body of a HTTP POST operation." --> I believe the POST operation shall be an application package which possibly does not include a process description ? Also, I don't expect a JSON server to support XML for the Process Description.
- Class OGC Application Package: in the schema make the processDescription optional. A lot of profile will generate the process description from the provided resources. This is even the typical serverless approach: you provide the source code (e.G. in git), and the I/O are extracted from the Python script or bash script (depending on the application type).
- Class OGC Application Package: executionUnit is probably a bad name. I suggest to rename it "processAsset", or "applicationAsset"
Similarly to various specification standards, I think that the spec should request a tailoring for each deployment profile, and define the information required in such tailoring. For example for "git repository of a Docker container" profile, a tailoring document should specify the specific application package schema, and detail how the information is used to generate the process description and to run the application.
I hope it helps :)
For anyone interested or for inspiration, I got advanced schema definitions of the whole Deploy going all the way down to the lowest type field of CWL definition for the Application Package:
https://pavics-weaver.readthedocs.io/en/schema-xmlexamples/api.html#tag/Processes/paths/~1processes/post
in the request body: executionUnit -> unit (CWL)
schemas: json
XML attribute definitions are also included in those schemas.