Suggestion: removing the inputs/outputs fields from the workflow object in cwl_log.json

[inutano]

The idea is from the problem that we can't extract the identifiers of the inputs/outputs to the workflow from the cwltool debug output.

For example, in the workflow file revsort.cwl of the conformance-53, the inputs to the workflow are described as below:

inputs:
  input:
    type: File
    doc: "The input file to be processed."
  reverse_sort:
    type: boolean
    default: true
    doc: "If true, reverse (descending) sort"

but those ids, "input" and "reverse_sort" do not appear in the debug output. The debug output only shows the identifiers of inputs to steps, which we have in the inputs field of each step. And it makes the generator not to catch the initial inputs to the workflow correctly, which results in a failure of the black box test.

So the possible solutions are:

1. Configure cwltool to show the initial inputs to the workflow in debug output
2. Let metrics analyzers to use inputs information of steps instead of workflow

I always prefer the easier way, so I suggest to remove the inputs/outputs field from workflow object in the cwl_log.json. I don't see much troubles that this may cause. I'm not using those fields in inutano/cwl-metrics-client as well.

Any ideas @tom-tan?

[tom-tan]

Do you use the latest version of cwltool?

By cwltool#834, cwltoool prints input and output objects for workflows as well as for command line tools. If the situation is the same with the latest version of cwltool, please let me know.

I confirmed make test works with cwltool 1.0.20181201184214.

[inutano]

You are right!!! I've confirmed with the same version, let me check if all the functions works as well

[inutano]

And still, it'd be worth considering if we still need the input/output fields in the workflow field

[tom-tan]

IMO they are necessary for several reasons.

• It enables us to use simple method to predict input and output file sizes for nested workflow. (I know cwl-metrics does not support it now but this decision will affect the future changes) Some resource planning methods need this kind of prediction as a preprocess phase.

  If there exist input and output objects for workflows, we can simply apply the same size prediction method even for nested workflows as well as simple workflows by treating the nested part as a single tool. Of course it is not fine-grained but it is good as the first step.

  If there are no input and output fields in the metrics, we, who want to use the metrics in our analysis or planning methods, may not use such simple strategies.

• For consistency. Tools have their inputs and outputs, and also workflow have their inputs and outputs in general. There are no reason to make the summary format inconsistent with the description format unless its implementation becomes complicated.