Fix issue #282 #404
Fix issue #282 #404
Conversation
Add /processes/{processId}/package path for accessing the formal description used to deploy a process
Add specific recommendations and requirements for OGC Application Package and CWL conformance classes
| ==== | ||
| [%metadata] | ||
| label:: /req/deploy-replace-undeploy/package/get-op | ||
| part:: For every dynamically added process (path: /processes/{processId}), the server SHALL support the HTTP GET operation at the path `/processes/{processId}/package`. |
There was a problem hiding this comment.
Include POST along with path: /processes/{processId} to avoid ambiguity with GET from core.
| label:: /req/cwl/package/response-body | ||
| part:: A response with HTTP status code `200` SHALL include a body that contains: | ||
| * the <<rc_cwl,CWL>> to use to deploy the process, in case the Content-Type used to deploy the process was `application/cwl`. | ||
| * the <<rc_ogcapppkg,OGC Application Package>> to use to deploy the process, in case the Content-Type used to deploy the process was `application/ogcapppkg+json`. |
There was a problem hiding this comment.
Should we consider the possibility that a package deployed one way could provide the representation of another encoding? For example, if deployed using CWL, it would be fairly easy to extract the relevant parts of the document to form the corresponding OGC Application Package format. An Accept header could allow the selection of one, an if conversion is supported, could help make instances more interoperable. If so, sentences mentioning that "if deployed with X, SHOULD support X" would have to be reworded slightly.
Or, do we want to make it explicit that the original format for deployment must be returned (no conversion permitted)? In such case, the Accept header is irrelevant.
There was a problem hiding this comment.
I vote yes, the implementation should be able to decide which package format it can return back.
There was a problem hiding this comment.
I also favor having the capability to choose between various formats. I agree that CWL (and maybe other encoding. supported in the future) can be converted into an OGC Application Package and vice versa. Nevertheless, I wonder if the Accept header should not be added to the 6.6.1 section, which describes the operation for retrieving the formal description.
Then, in the 6.6 Retrieving the formal description section, we would add another section: Exception specifying what happens if the Accept header is not supported.
The unsupported-media-type exception type is possible if the media type is not supported. However, it's important to note that the exception could be something else if the process cannot be exposed in the desired encoding. For instance, consider a Docker image used to publish a process as an OGC Application Package, then a request /processes/{processId}/package using Accept header set to application/cwl should get back an exception that would help the client application determine that the issue comes from the fact that the conversion is impossible (maybe a type set to http://www.opengis.net/def/exceptions/ogcapi-processes-2/1.0/incompatible-media-type).
What do you think?
There was a problem hiding this comment.
Isn't the use the "Accept" header already implied but clause 7.5 "Use of HTTP 1.1"?
There was a problem hiding this comment.
SWG meeting from April 29th: Add a note that you can request the application package in a format other than originally used using the accept header. Examples: If cwl is explicitly requested and the server cannot handle it that a HTTP 406 should be returned.
| application/cwl: | ||
| schema: | ||
| $ref: "https://raw.githubusercontent.com/common-workflow-language/cwl-v1.2/1.2.1_proposed/json-schema/cwl.yaml" | ||
| application/cwl+json: | ||
| schema: | ||
| $ref: "https://raw.githubusercontent.com/common-workflow-language/cwl-v1.2/1.2.1_proposed/json-schema/cwl.yaml" | ||
| application/cwl+yaml: | ||
| schema: | ||
| $ref: "https://raw.githubusercontent.com/common-workflow-language/cwl-v1.2/1.2.1_proposed/json-schema/cwl.yaml" |
There was a problem hiding this comment.
The URI is not valid anymore (to fix in other parts of the spec as well).
I already flagged the issue here: common-workflow-language/cwl-v1.2#278 (comment)
Waiting for their feedback for an official location.
| [[deploy-replace-undeploy-package]] | ||
| === Retrieving the formal description | ||
|
|
||
| For every process deployed to the server, it is possible to retrieve its formal description. It corresponds to the request's body used to deploy or replace the process. |
There was a problem hiding this comment.
Perhaps this wording is more clear? "For every mutable process, it is possible to retrieve the application package that was used to deploy the process."
There was a problem hiding this comment.
The "mutable" process part raises a good question. What about immutable ones? I have some processes that are immutable, but still represented using CWL. The echo process is a good example of this, as it comes "pre-deployed" with the service.
There was a problem hiding this comment.
@fmigneault clients know which processes are mutable or not since there is a member in the process description that indicates that. So, clients should not request the "package" of an immutable process since there is no guarantee that the "package" exists. The process may, for example, be compiled right into the executable of the server.
In the event that a client does ask for the package for an immutable process then they should be prepared to get a 404. I am not saying that they will get a 404; if the server has the package or can generate it (as is your case), then the server can offer it up but in the event that a package does not exist the client should be prepared to get a 404. At least that is was I think should happen. Thoughts?
There was a problem hiding this comment.
Yes. That is reasonable.
As discussed on April 15, 2024, during the SWG meeting, we propose the following additions.
Add /processes/{processId}/package path for accessing the formal description used to deploy a process.
Add specific recommendations and requirements for the OGC Application Package and CWL conformance classes.