First cut of input and output bindings in the execution unit.

[pvretano]

No description provided.

[fmigneault]

Looks good.
My only concern is that the closer it gets to looking like CWL while "not being quite all of it" (e.g.: JavaScript expression support?), the more it feels like the server should probably just support CWL deployment instead.

If the bindings limit themselves to the currently proposed definitions (prefix, position, etc.) to obtain the container's command line call, it is fine to quickly patch the OGC AppPkg required but missing features. The standard should probably present the 2 options (OGC AppPkg / CWL), and mention something along the lines of "if you need more advanced workflow language capabilities, use CWL". The idea being that OGC AppPkg purposely does not try to replicate all capabilities CWL handles, just the bare minimum needed (and making sure users don't start opening many issues about unsupported CWL behaviours).

From my experience, the CWL $(inputs.myInput.path) and other JavaScript expressions are often used within Workflows, within CWL additional requirements (eg: InitialWorkDirRequirement), or to work around CWL-specifc quirks. I would suggest removing JavaScript expressions from OGC AppPkg to keep it simple, and let these complex features be more extensively defined within CWL.

[pvretano]

@fmigneault I agree that the "closer" it looks like CWL then a server implementation should just use CWL.

However, since OGC APP PKG is still in the standard and it is missing this one important bit that allows the mapping from process input to command line then we should add something and since CWL has already done the hard work of figuring out what is needed, it makes sense to steal and adapt this one little bit of CWL into OGC APP PKG.

Eventually we will deprecate OGC APP PKG and remove it altogether if no one is using it.

Thanks for the other feedback ...

[fmigneault]

I think OGC APP PKG is great (and should stay) for the purpose of "quickly deploying a docker" (for example), since supporting CWL can be considered overkill (understandably) by certain implementers. I think the JavaScript expressions enter the realm of the "overly complex" for OGC APP PKG.

[pvretano]

@fmigneault since my server only fully supports OGC APP PKG and very partially supports CWL (experimental) at the moment I can't disagree with you! LOL!

[gfenoy]

I agree that the OGC Application Package should stay, also to support multiple CWLs.

The current OGC Application Package schema enables passing a CWL by reference or by value, as we do with inputs in an execute request. It supports an array of execution units, offering an option to merge multiple CWL into one. Ie, when a workflow defined in A.cwl references other CWL files, ie, using run: B.cwl. You can use an array with a reference to all the required CWLs and get it properly deployed. It is the responsibility of the server to produce the single CWL containing all the referenced CWL or handle them as-is at execution time.

[pvretano]

@fmigneault @gfenoy agreed! OGC APP PKS stays. It was not going anywhere any time soon anyway. I was just speculating that at some point in the future it might be deprecated. Nothing we need to worry about now. Thanks for all the feedback!