Part 3: proposal for functional CWL ad-hoc execution with multipart

[fmigneault]

This proposal adjusts the Part 3 Workflow and Chaining definitions regarding ad-hoc CWL definitions and makes them actionable.

Specifically, it proposes using Multipart contents aligned with recent updates of Part 2: DRU to provide the CWL + execution body. Since the DRU structure defines how to deploy such multipart process, it is fairly easy to extend it with just one extra "Execute" part, to do ad-hoc "deploy" and execute it right away within a single request.

As proof, we already have a working implementation that required only small adjustments to make it work crim-ca/weaver#997.

Because CWL is a workflow definition (not "runtime", in contrast to Nested Processes that mix the process-chain and values right away), it has limited use by itself in an execution request. Implementations would have to perform some workarounds with valueFrom to force values into the CWL. While technically possible (and showcased in the proposed edits), it is not as nice to define workflows this way (and from experice, it gets ugly and less reusable with convoluted large data values like a FeatureCollection, also tested: https://github.com/crim-ca/weaver/blob/master/tests/functional/application-packages/EchoFeatures/echo_features.cwl, https://github.com/crim-ca/weaver/blob/master/tests/functional/application-packages/EchoFeatures/execute.yml).

Therefore, the proposal is to keep CWL definition and OGC Execution separate, where each of their respective validation schema are well established. That allows implementation to perform robust validation of each component on its own, which is more interoperable, and then merge them during the ad-hoc execution with their preferred workflow engine/implementation to deal with runtime complexities.

@jerstlouis @pvretano @gfenoy Let me know what you think of it.