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.

[pvretano]

14SEP2026: @fmigneault will fix inputBinding/outputBinding to inputBindings/outputBindings and then merge.

[fmigneault]

@pvretano
I think the actual CI on OGC side relies on https://github.com/opengeospatial/ogcapi-processes/blob/master/metanorma.yml
If it used https://github.com/opengeospatial/ogcapi-processes/blob/master/ogcmetanorma.json, it would never have build Part 3 as it didn't even point at the right place! (see 5270bd0)
Maybe that file should be removed if that can be validated by OGC staff? (@gbuehler ?)

Requested change (#607 (comment)) is done and local CI works now.

[pvretano]

@fmigneault I'll ping @gbuehler via email to take a look.

[gbuehler]

@fmigneault @pvretano Actually, I do not use ogcmetanorma.json to build, which I suppose is a big misunderstanding. The CI/CD each repo does is up to the editors of the documents/standards. I just clone the repo and do the DRAFTS build on our server based upon the editor's request to put the documents up in DRAFTS.

[fmigneault]

@gbuehler Just to be sure I understand. The build on OGC side is configured separately and not hosted in this repository's configurations? If that's the case, I propose doing some cleanup (can be another PR not to block this one).

I just noticed as well a 3rd reference https://github.com/opengeospatial/ogcapi-processes/blob/master/asciidoctor.json with similar contents. I think @jerstlouis was using asciidoctor to go faster than what metanorma does. Ideally we pick one that all tools can understand.

[gbuehler]

@fmigneault, the asciidoctor.json is still used for repos that need their documents built using the old AsciiDoc templates and not Metanorma. If there are no documents in the repo that require an asciidoctor rendering, that can be completely removed. As long as the paths to the documents that need to be built for DRAFTS do not change and the document numbers stay the same, you should be fine to do clean up. Here is the local config I build from:

[
{
"location": "ogcapi-processes",
"repo": "ogcapi-processes",
"branch": "",
"folder": "extensions/deploy_replace_undeploy/standard/",
"docname": "20-044",
"docnum": "20-044"
},
{
"location": "ogcapi-processes",
"repo": "ogcapi-processes",
"branch": "",
"folder": "extensions/workflows/",
"docname": "21-009",
"docnum": "21-009"
},
{
"location": "ogcapi-processes",
"repo": "ogcapi-processes",
"branch": "",
"folder": "/",
"docname": "18-062",
"docnum": "18-062r3"
},
{
"location": "ogcapi-processes",
"repo": "ogcapi-processes",
"branch": "",
"folder": "extensions/job_management/standard/",
"docname": "24-051",
"docnum": "24-051"
},
{
"location": "ogcapi-processes",
"repo": "ogcapi-processes",
"branch": "",
"folder": "extensions/provenance/standard/",
"docname": "26-038",
"docnum": "26-038"
}
]