Common Workflow Language (CWL) Workflow Description, v1.0.2 &sect;

steps

required

array<WorkflowStep> |
map<id, WorkflowStep>

The individual steps that make up the workflow. Each step is executed when all of its input data links are fufilled. An implementation may choose to execute the steps in a different order than listed and/or execute steps concurrently, provided that dependencies between steps are met.

id

optional

The unique identifier for this process object.

requirements

optional

Declares requirements that apply to either the runtime environment or the workflow engine that must be met in order to execute this process. If an implementation cannot satisfy all requirements, or a requirement is listed which is not recognized by the implementation, it is a fatal error and the implementation must not attempt to run the process, unless overridden at user option.

hints

optional

array<Any> | map<class, Any>

Declares hints applying to either the runtime environment or the workflow engine that may be helpful in executing this process. It is not an error if an implementation cannot satisfy all hints, however the implementation may report a warning.

label

optional

A short, human-readable label of this process object.

doc

optional

A long, human-readable description of this process object.

cwlVersion

optional

CWLVersion

CWL document version. Always required at the document root. Not required for a Process embedded inside another Process.

4.1 WorkflowOutputParameter §

Describe an output parameter of a workflow. The parameter must be connected to one or more parameters defined in the workflow that will provide the value of the output parameter.

Fields

field

required

type

description

id

required

The unique identifier for this parameter object.

label

optional

A short, human-readable label of this object.

secondaryFiles

optional

string | Expression | array<string | Expression>

Only valid when type: File or is an array of items: File.

Provides a pattern or expression specifying files or directories that must be included alongside the primary file. All listed secondary files must be present. An implementation may fail workflow execution if an expected secondary file does not exist.

If the value is an expression, the value of self in the expression must be the primary input or output File object to which this binding applies. The basename, nameroot and nameext fields must be present in self. For CommandLineTool outputs the path field must also be present. The expression must return a filename string relative to the path to the primary File, a File or Directory object with either path or location and basename fields set, or an array consisting of strings or File or Directory objects. It is legal to reference an unchanged File or Directory object taken from input as a secondaryFile.

To work on non-filename-preserving storage systems, portable tool descriptions should avoid constructing new values from location, but should construct relative references using basename or nameroot instead.

If a value in secondaryFiles is a string that is not an expression, it specifies that the following pattern should be applied to the path of the primary file to yield a filename relative to the primary File:

If string begins with one or more caret ^ characters, for each caret, remove the last file extension from the path (the last period . and all following characters). If there are no file extensions, the path is unchanged.
Append the remainder of the string to the end of the file path.

streamable

optional

Only valid when type: File or is an array of items: File.

A value of true indicates that the file is read or written sequentially without seeking. An implementation may use this flag to indicate whether it is valid to stream file contents using a named pipe. Default: false.

doc

optional

string | array<string>

A documentation string for this type, or an array of strings which should be concatenated.

outputBinding

optional

Describes how to handle the outputs of a process.

format

optional

Only valid when type: File or is an array of items: File.

This is the file format that will be assigned to the output parameter.

outputSource

optional

string | array<string>

Specifies one or more workflow parameters that supply the value of to the output parameter.

linkMerge

optional

LinkMergeMethod

The method to use to merge multiple sources into a single array. If not specified, the default method is "merge_nested".

type

optional

Specify valid types of data that may be assigned to this parameter.

4.1.1 Expression §

'Expression' is not a real type. It indicates that a field must allow runtime parameter references. If InlineJavascriptRequirement is declared and supported by the platform, the field must also allow Javascript expressions.

Symbols

symbol	description
`ExpressionPlaceholder`

4.1.2 CommandOutputBinding §

Describes how to generate an output parameter based on the files produced by a CommandLineTool.

The output parameter value is generated by applying these operations in the following order:

glob
loadContents
outputEval
secondaryFiles

Fields

field

required

type

description

glob

optional

string | Expression | array<string>

Find files relative to the output directory, using POSIX glob(3) pathname matching. If an array is provided, find files that match any pattern in the array. If an expression is provided, the expression must return a string or an array of strings, which will then be evaluated as one or more glob patterns. Must only match and return files which actually exist.

loadContents

optional

For each file matched in glob, read up to the first 64 KiB of text from the file and place it in the contents field of the file object for manipulation by outputEval.

outputEval

optional

Evaluate an expression to generate the output value. If glob was specified, the value of self must be an array containing file objects that were matched. If no files were matched, self must be a zero length array; if a single file was matched, the value of self is an array of a single element. Additionally, if loadContents is true, the File objects must include up to the first 64 KiB of file contents in the contents field.

4.1.3 LinkMergeMethod §

The input link merge method, described in WorkflowStepInput.

Symbols

symbol	description
`merge_nested`
`merge_flattened`

4.1.4 CWLType §

Extends primitive types with the concept of a file and directory as a builtin type.

Symbols

symbol	description
`null`	no value
`boolean`	a binary value
`int`	32-bit signed integer
`long`	64-bit signed integer
`float`	single precision (32-bit) IEEE 754 floating-point number
`double`	double precision (64-bit) IEEE 754 floating-point number
`string`	Unicode character sequence
`null`	no value
`boolean`	a binary value
`int`	32-bit signed integer
`long`	64-bit signed integer
`float`	single precision (32-bit) IEEE 754 floating-point number
`double`	double precision (64-bit) IEEE 754 floating-point number
`string`	Unicode character sequence
`File`	A File object
`Directory`	A Directory object

4.1.5 File §

Represents a file (or group of files when secondaryFiles is provided) that will be accessible by tools using standard POSIX file system call API such as open(2) and read(2).

Files are represented as objects with class of File. File objects have a number of properties that provide metadata about the file.

The location property of a File is a URI that uniquely identifies the file. Implementations must support the file:// URI scheme and may support other schemes such as http://. The value of location may also be a relative reference, in which case it must be resolved relative to the URI of the document it appears in. Alternately to location, implementations must also accept the path property on File, which must be a filesystem path available on the same host as the CWL runner (for inputs) or the runtime environment of a command line tool execution (for command line tool outputs).

If no location or path is specified, a file object must specify contents with the UTF-8 text content of the file. This is a "file literal". File literals do not correspond to external resources, but are created on disk with contents with when needed for a executing a tool. Where appropriate, expressions can return file literals to define new files on a runtime. The maximum size of contents is 64 kilobytes.

The basename property defines the filename on disk where the file is staged. This may differ from the resource name. If not provided, basename must be computed from the last path part of location and made available to expressions.

The secondaryFiles property is a list of File or Directory objects that must be staged in the same directory as the primary file. It is an error for file names to be duplicated in secondaryFiles.

The size property is the size in bytes of the File. It must be computed from the resource and made available to expressions. The checksum field contains a cryptographic hash of the file content for use it verifying file contents. Implementations may, at user option, enable or disable computation of the checksum field for performance or other reasons. However, the ability to compute output checksums is required to pass the CWL conformance test suite.

When executing a CommandLineTool, the files and secondary files may be staged to an arbitrary directory, but must use the value of basename for the filename. The path property must be file path in the context of the tool execution runtime (local to the compute node, or within the executing container). All computed properties should be available to expressions. File literals also must be staged and path must be set.

When collecting CommandLineTool outputs, glob matching returns file paths (with the path property) and the derived properties. This can all be modified by outputEval. Alternately, if the file cwl.output.json is present in the output, outputBinding is ignored.

File objects in the output must provide either a location URI or a path property in the context of the tool execution runtime (local to the compute node, or within the executing container).

When evaluating an ExpressionTool, file objects must be referenced via location (the expression tool does not have access to files on disk so path is meaningless) or as file literals. It is legal to return a file object with an existing location but a different basename. The loadContents field of ExpressionTool inputs behaves the same as on CommandLineTool inputs, however it is not meaningful on the outputs.

An ExpressionTool may forward file references from input to output by using the same value for location.

Fields

field

required

type

description

class

required

constant value File

Must be File to indicate this object describes a file.

location

optional

An IRI that identifies the file resource. This may be a relative reference, in which case it must be resolved using the base IRI of the document. The location may refer to a local or remote resource; the implementation must use the IRI to retrieve file content. If an implementation is unable to retrieve the file content stored at a remote resource (due to unsupported protocol, access denied, or other issue) it must signal an error.

If the location field is not provided, the contents field must be provided. The implementation must assign a unique identifier for the location field.

If the path field is provided but the location field is not, an implementation may assign the value of the path field to location, then follow the rules above.

path

optional

The local host path where the File is available when a CommandLineTool is executed. This field must be set by the implementation. The final path component must match the value of basename. This field must not be used in any other context. The command line tool being executed must be able to to access the file at path using the POSIX open(2) syscall.

As a special case, if the path field is provided but the location field is not, an implementation may assign the value of the path field to location, and remove the path field.

If the path contains POSIX shell metacharacters (|,&, ;, <, >, (,), $,`, \, ", ', <space>, <tab>, and <newline>) or characters not allowed for Internationalized Domain Names for Applications then implementations may terminate the process with a permanentFailure.

basename

optional

The base name of the file, that is, the name of the file without any leading directory path. The base name must not contain a slash /.

If not provided, the implementation must set this field based on the location field by taking the final path component after parsing location as an IRI. If basename is provided, it is not required to match the value from location.

When this file is made available to a CommandLineTool, it must be named with basename, i.e. the final component of the path field must match basename.

dirname

optional

The name of the directory containing file, that is, the path leading up to the final slash in the path such that dirname + '/' + basename == path.

The implementation must set this field based on the value of path prior to evaluating parameter references or expressions in a CommandLineTool document. This field must not be used in any other context.

nameroot

optional

The basename root such that nameroot + nameext == basename, and nameext is empty or begins with a period and contains at most one period. For the purposess of path splitting leading periods on the basename are ignored; a basename of .cshrc will have a nameroot of .cshrc.

The implementation must set this field automatically based on the value of basename prior to evaluating parameter references or expressions.

nameext

optional

The basename extension such that nameroot + nameext == basename, and nameext is empty or begins with a period and contains at most one period. Leading periods on the basename are ignored; a basename of .cshrc will have an empty nameext.

The implementation must set this field automatically based on the value of basename prior to evaluating parameter references or expressions.

checksum

optional

Optional hash code for validating file integrity. Currently must be in the form "sha1$ + hexadecimal string" using the SHA-1 algorithm.

size

optional

long

Optional file size

secondaryFiles

optional

array<File | Directory>

A list of additional files or directories that are associated with the primary file and must be transferred alongside the primary file. Examples include indexes of the primary file, or external references which must be included when loading primary document. A file object listed in secondaryFiles may itself include secondaryFiles for which the same rules apply.

format

optional

The format of the file: this must be an IRI of a concept node that represents the file format, preferrably defined within an ontology. If no ontology is available, file formats may be tested by exact match.

Reasoning about format compatability must be done by checking that an input file format is the same, owl:equivalentClass or rdfs:subClassOf the format required by the input parameter. owl:equivalentClass is transitive with rdfs:subClassOf, e.g. if <B> owl:equivalentClass <C> and <B> owl:subclassOf <A> then infer <C> owl:subclassOf <A>.

File format ontologies may be provided in the "$schemas" metadata at the root of the document. If no ontologies are specified in $schemas, the runtime may perform exact file format matches.

contents

optional

File contents literal. Maximum of 64 KiB.

If neither location nor path is provided, contents must be non-null. The implementation must assign a unique identifier for the location field. When the file is staged as input to CommandLineTool, the value of contents must be written to a file.

If loadContents of inputBinding or outputBinding is true and location is valid, the implementation must read up to the first 64 KiB of text from the file and place it in the "contents" field.

4.1.5.1 Directory §

Represents a directory to present to a command line tool.

Directories are represented as objects with class of Directory. Directory objects have a number of properties that provide metadata about the directory.

The location property of a Directory is a URI that uniquely identifies the directory. Implementations must support the file:// URI scheme and may support other schemes such as http://. Alternately to location, implementations must also accept the path property on Directory, which must be a filesystem path available on the same host as the CWL runner (for inputs) or the runtime environment of a command line tool execution (for command line tool outputs).

A Directory object may have a listing field. This is a list of File and Directory objects that are contained in the Directory. For each entry in listing, the basename property defines the name of the File or Subdirectory when staged to disk. If listing is not provided, the implementation must have some way of fetching the Directory listing at runtime based on the location field.

If a Directory does not have location, it is a Directory literal. A Directory literal must provide listing. Directory literals must be created on disk at runtime as needed.

The resources in a Directory literal do not need to have any implied relationship in their location. For example, a Directory listing may contain two files located on different hosts. It is the responsibility of the runtime to ensure that those files are staged to disk appropriately. Secondary files associated with files in listing must also be staged to the same Directory.

When executing a CommandLineTool, Directories must be recursively staged first and have local values of path assigend.

Directory objects in CommandLineTool output must provide either a location URI or a path property in the context of the tool execution runtime (local to the compute node, or within the executing container).

An ExpressionTool may forward file references from input to output by using the same value for location.

Name conflicts (the same basename appearing multiple times in listing or in any entry in secondaryFiles in the listing) is a fatal error.

Fields

field

required

type

description

class

required

constant value Directory

Must be Directory to indicate this object describes a Directory.

location

optional

An IRI that identifies the directory resource. This may be a relative reference, in which case it must be resolved using the base IRI of the document. The location may refer to a local or remote resource. If the listing field is not set, the implementation must use the location IRI to retrieve directory listing. If an implementation is unable to retrieve the directory listing stored at a remote resource (due to unsupported protocol, access denied, or other issue) it must signal an error.

If the location field is not provided, the listing field must be provided. The implementation must assign a unique identifier for the location field.

If the path field is provided but the location field is not, an implementation may assign the value of the path field to location, then follow the rules above.

path

optional

The local path where the Directory is made available prior to executing a CommandLineTool. This must be set by the implementation. This field must not be used in any other context. The command line tool being executed must be able to to access the directory at path using the POSIX opendir(2) syscall.

basename

optional

The base name of the directory, that is, the name of the file without any leading directory path. The base name must not contain a slash /.

When this file is made available to a CommandLineTool, it must be named with basename, i.e. the final component of the path field must match basename.

listing

optional

array<File | Directory>

List of files or subdirectories contained in this directory. The name of each file or subdirectory is determined by the basename field of each File or Directory object. It is an error if a File shares a basename with any other entry in listing. If two or more Directory object share the same basename, this must be treated as equivalent to a single subdirectory with the listings recursively merged.

4.1.6 OutputRecordSchema §

Fields

field

required

type

description

type

required

constant value record

Must be record

fields

optional

array<OutputRecordField> |
map<name, type | OutputRecordField>

Defines the fields of the record.

label

optional

A short, human-readable label of this object.

4.1.7 OutputRecordField §

Fields

field

required

type

description

name

required

The name of the field

type

required

The field type

doc

optional

A documentation string for this field

outputBinding

optional

4.1.7.1 OutputEnumSchema §

Fields

field

required

type

description

symbols

required

array<string>

Defines the set of valid symbols.

type

required

constant value enum

Must be enum

label

optional

A short, human-readable label of this object.

outputBinding

optional

4.1.7.2 OutputArraySchema §

Fields

field

required

type

description

items

required

Defines the type of the array elements.

type

required

constant value array

Must be array

label

optional

A short, human-readable label of this object.

outputBinding

optional

4.2 WorkflowStep §

A workflow step is an executable element of a workflow. It specifies the underlying process implementation (such as CommandLineTool or another Workflow) in the run field and connects the input and output parameters of the underlying process to workflow parameters.

Scatter/gather §

To use scatter/gather, ScatterFeatureRequirement must be specified in the workflow or workflow step requirements.

A "scatter" operation specifies that the associated workflow step or subworkflow should execute separately over a list of input elements. Each job making up a scatter operation is independent and may be executed concurrently.

The scatter field specifies one or more input parameters which will be scattered. An input parameter may be listed more than once. The declared type of each input parameter is implicitly becomes an array of items of the input parameter type. If a parameter is listed more than once, it becomes a nested array. As a result, upstream parameters which are connected to scattered parameters must be arrays.

All output parameter types are also implicitly wrapped in arrays. Each job in the scatter results in an entry in the output array.

If any scattered parameter runtime value is an empty array, all outputs are set to empty arrays and no work is done for the step, according to applicable scattering rules.

If scatter declares more than one input parameter, scatterMethod describes how to decompose the input into a discrete set of jobs.

dotproduct specifies that each of the input arrays are aligned and one element taken from each array to construct each job. It is an error if all input arrays are not the same length.
nested_crossproduct specifies the Cartesian product of the inputs, producing a job for every combination of the scattered inputs. The output must be nested arrays for each level of scattering, in the order that the input arrays are listed in the scatter field.
flat_crossproduct specifies the Cartesian product of the inputs, producing a job for every combination of the scattered inputs. The output arrays must be flattened to a single level, but otherwise listed in the order that the input arrays are listed in the scatter field.

Subworkflows §

To specify a nested workflow as part of a workflow step, SubworkflowFeatureRequirement must be specified in the workflow or workflow step requirements.

It is a fatal error if a workflow directly or indirectly invokes itself as a subworkflow (recursive workflows are not allowed).

Fields

field

required

type

description

id

required

The unique identifier for this workflow step.

in

required

array<WorkflowStepInput> |
map<id, source | WorkflowStepInput>

Defines the input parameters of the workflow step. The process is ready to run when all required input parameters are associated with concrete values. Input parameters include a schema for each parameter which is used to validate the input object. It may also be used build a user interface for constructing the input object.

out

required

array<string | WorkflowStepOutput>

Defines the parameters representing the output of the process. May be used to generate and/or validate the output object.

run

required

string | CommandLineTool | ExpressionTool | Workflow

Specifies the process to run.

requirements

optional

Declares requirements that apply to either the runtime environment or the workflow engine that must be met in order to execute this workflow step. If an implementation cannot satisfy all requirements, or a requirement is listed which is not recognized by the implementation, it is a fatal error and the implementation must not attempt to run the process, unless overridden at user option.

hints

optional

array<Any> | map<class, Any>

Declares hints applying to either the runtime environment or the workflow engine that may be helpful in executing this workflow step. It is not an error if an implementation cannot satisfy all hints, however the implementation may report a warning.

label

optional

A short, human-readable label of this process object.

doc

optional

A long, human-readable description of this process object.

scatter

optional

string | array<string>

scatterMethod

optional

ScatterMethod

Required if scatter is an array of more than one element.

4.2.1 WorkflowStepInput §

The input of a workflow step connects an upstream parameter (from the workflow inputs, or the outputs of other workflows steps) with the input parameters of the underlying step.

Input object §

A WorkflowStepInput object must contain an id field in the form #fieldname or #prefix/fieldname. When the id field contains a slash / the field name consists of the characters following the final slash (the prefix portion may contain one or more slashes to indicate scope). This defines a field of the workflow step input object with the value of the source parameter(s).

Merging §

To merge multiple inbound data links, MultipleInputFeatureRequirement must be specified in the workflow or workflow step requirements.

If the sink parameter is an array, or named in a workflow scatter operation, there may be multiple inbound data links listed in the source field. The values from the input links are merged depending on the method specified in the linkMerge field. If not specified, the default method is "merge_nested".

merge_nested

The input must be an array consisting of exactly one entry for each input link. If "merge_nested" is specified with a single link, the value from the link must be wrapped in a single-item list.
merge_flattened
1. The source and sink parameters must be compatible types, or the source type must be compatible with single element from the "items" type of the destination array parameter.
2. Source parameters which are arrays are concatenated. Source parameters which are single element types are appended as single elements.

Fields

field

required

type

description

id

required

A unique identifier for this workflow input parameter.

source

optional

string | array<string>

Specifies one or more workflow parameters that will provide input to the underlying step parameter.

linkMerge

optional

LinkMergeMethod

The method to use to merge multiple inbound links into a single array. If not specified, the default method is "merge_nested".

default

optional

Any

The default value for this parameter to use if either there is no source field, or the value produced by the source is null. The default must be applied prior to scattering or evaluating valueFrom.

valueFrom

optional

To use valueFrom, StepInputExpressionRequirement must be specified in the workflow or workflow step requirements.

If valueFrom is a constant string value, use this as the value for this input parameter.

If valueFrom is a parameter reference or expression, it must be evaluated to yield the actual value to be assiged to the input field.

The self value in the parameter reference or expression must be parameter is specified in this workflow step's scatter field.

null if there is no source field
the value of the parameter(s) specified in the source field when this workflow input parameter is not specified in this workflow step's scatter field.
an element of the parameter specified in the source field when this workflow input

The value of inputs in the parameter reference or expression must be the input object to the workflow step after assigning the source values, applying default, and then scattering. The order of evaluating valueFrom among step input parameters is undefined and the result of evaluating valueFrom on a parameter must not be visible to evaluation of valueFrom on other parameters.

4.2.1.1 Any §

The Any type validates for any non-null value.

Symbols

symbol	description
`Any`

4.2.2 WorkflowStepOutput §

Associate an output parameter of the underlying process with a workflow parameter. The workflow parameter (given in the id field) be may be used as a source to connect with input parameters of other workflow steps, or with an output parameter of the process.

Fields

field

required

type

description

id

required

A unique identifier for this workflow output parameter. This is the identifier to use in the source field of WorkflowStepInput to connect the output value to downstream parameters.

4.2.3 ScatterMethod §

The scatter method, as described in workflow step scatter.

Symbols

symbol	description
`dotproduct`
`nested_crossproduct`
`flat_crossproduct`

4.2.4 InlineJavascriptRequirement §

Indicates that the workflow platform must support inline Javascript expressions. If this requirement is not present, the workflow platform must not perform expression interpolatation.

Fields

field

required

type

description

class

required

Always 'InlineJavascriptRequirement'

expressionLib

optional

array<string>

Additional code fragments that will also be inserted before executing the expression code. Allows for function definitions that may be called from CWL expressions.

4.2.5 SchemaDefRequirement §

This field consists of an array of type definitions which must be used when interpreting the inputs and outputs fields. When a type field contain a IRI, the implementation must check if the type is defined in schemaDefs and use that definition. If the type is not found in schemaDefs, it is an error. The entries in schemaDefs must be processed in the order listed such that later schema definitions may refer to earlier schema definitions.

Fields

field

required

type

description

class

required

Always 'SchemaDefRequirement'

types

required

array<InputRecordSchema | InputEnumSchema | InputArraySchema>

The list of type definitions.

4.2.5.1 InputRecordSchema §

Fields

field

required

type

description

type

required

constant value record

Must be record

fields

optional

array<InputRecordField> |
map<name, type | InputRecordField>

Defines the fields of the record.

label

optional

A short, human-readable label of this object.

name

optional

4.2.5.2 InputRecordField §

Fields

field

required

type

description

name

required

The name of the field

type

required

The field type

doc

optional

A documentation string for this field

inputBinding

optional

label

optional

A short, human-readable label of this process object.

4.2.5.2.1 InputEnumSchema §

Fields

field

required

type

description

symbols

required

array<string>

Defines the set of valid symbols.

type

required

constant value enum

Must be enum

label

optional

A short, human-readable label of this object.

name

optional

inputBinding

optional

4.2.5.2.2 CommandLineBinding §

When listed under inputBinding in the input schema, the term "value" refers to the the corresponding value in the input object. For binding objects listed in CommandLineTool.arguments, the term "value" refers to the effective value after evaluating valueFrom.

The binding behavior when building the command line depends on the data type of the value. If there is a mismatch between the type described by the input schema and the effective value, such as resulting from an expression evaluation, an implementation must use the data type of the effective value.

string: Add prefix and the string to the command line.
number: Add prefix and decimal representation to command line.
boolean: If true, add prefix to the command line. If false, add nothing.
File: Add prefix and the value of File.path to the command line.
Directory: Add prefix and the value of Directory.path to the command line.
array: If itemSeparator is specified, add prefix and the join the array into a single string with itemSeparator separating the items. Otherwise first add prefix, then recursively process individual elements. If the array is empty, it does not add anything to command line.
object: Add prefix only, and recursively add object fields for which inputBinding is specified.
null: Add nothing.

Fields

field

required

type

description

loadContents

optional

Only valid when type: File or is an array of items: File.

Read up to the first 64 KiB of text from the file and place it in the "contents" field of the file object for use by expressions.

position

optional

int

The sorting key. Default position is 0.

prefix

optional

Command line prefix to add before the value.

separate

optional

If true (default), then the prefix and value must be added as separate command line arguments; if false, prefix and value must be concatenated into a single command line argument.

itemSeparator

optional

Join the array elements into a single string with the elements separated by by itemSeparator.

valueFrom

optional

If valueFrom is a constant string value, use this as the value and apply the binding rules above.

If valueFrom is an expression, evaluate the expression to yield the actual value to use to build the command line and apply the binding rules above. If the inputBinding is associated with an input parameter, the value of self in the expression will be the value of the input parameter. Input parameter defaults (as specified by the InputParameter.default field) must be applied before evaluating the expression.

When a binding is part of the CommandLineTool.arguments field, the valueFrom field is required.

shellQuote

optional

If ShellCommandRequirement is in the requirements for the current command, this controls whether the value is quoted on the command line (default is true). Use shellQuote: false to inject metacharacters for operations such as pipes.

If shellQuote is true or not provided, the implementation must not permit interpretation of any shell metacharacters or directives.

4.2.5.2.3 InputArraySchema §

Fields

field

required

type

description

items

required

Defines the type of the array elements.

type

required

constant value array

Must be array

label

optional

A short, human-readable label of this object.

inputBinding

optional

4.2.6 SoftwareRequirement §

A list of software packages that should be configured in the environment of the defined process.

Fields

field

required

type

description

class

required

Always 'SoftwareRequirement'

packages

required

array<SoftwarePackage> |
map<package, specs | SoftwarePackage>

The list of software to be configured.

4.2.7 SoftwarePackage §

Fields

field

required

type

description

package

required

The name of the software to be made available. If the name is common, inconsistent, or otherwise ambiguous it should be combined with one or more identifiers in the specs field.

version

optional

array<string>

The (optional) versions of the software that are known to be compatible.

specs

optional

array<string>

One or more IRIs identifying resources for installing or enabling the software named in the package field. Implementations may provide resolvers which map these software identifer IRIs to some configuration action; or they can use only the name from the package field on a best effort basis.

For example, the IRI https://packages.debian.org/bowtie could be resolved with apt-get install bowtie. The IRI https://anaconda.org/bioconda/bowtie could be resolved with conda install -c bioconda bowtie.

IRIs can also be system independent and used to map to a specific software installation or selection mechanism. Using RRID as an example: https://identifiers.org/rrid/RRID:SCR_005476 could be fulfilled using the above mentioned Debian or bioconda package, a local installation managed by Environement Modules, or any other mechanism the platform chooses. IRIs can also be from identifer sources that are discipline specific yet still system independent. As an example, the equivalent ELIXIR Tools and Data Service Registry IRI to the previous RRID example is https://bio.tools/tool/bowtie2/version/2.2.8. If supported by a given registry, implementations are encouraged to query these system independent sofware identifier IRIs directly for links to packaging systems.

A site specific IRI can be listed as well. For example, an academic computing cluster using Environement Modules could list the IRI https://hpc.example.edu/modules/bowtie-tbb/1.22 to indicate that module load bowtie-tbb/1.1.2 should be executed to make available bowtie version 1.1.2 compiled with the TBB library prior to running the accompanying Workflow or CommandLineTool. Note that the example IRI is specific to a particular institution and computing environment as the Environment Modules system does not have a common namespace or standardized naming convention.

This last example is the least portable and should only be used if mechanisms based off of the package field or more generic IRIs are unavailable or unsuitable. While harmless to other sites, site specific software IRIs should be left out of shared CWL descriptions to avoid clutter.

4.2.8 InitialWorkDirRequirement §

Define a list of files and subdirectories that must be created by the workflow platform in the designated output directory prior to executing the command line tool.

Fields

field

required

type

description

class

required

InitialWorkDirRequirement

listing

required

The list of files or subdirectories that must be placed in the designated output directory prior to executing the command line tool.

May be an expression. If so, the expression return value must validate as {type: array, items: [File, Directory]}.

Files or Directories which are listed in the input parameters and appear in the InitialWorkDirRequirement listing must have their path set to their staged location in the designated output directory. If the same File or Directory appears more than once in the InitialWorkDirRequirement listing, the implementation must choose exactly one value for path; how this value is chosen is undefined.

4.2.8.1 Dirent §

Define a file or subdirectory that must be placed in the designated output directory prior to executing the command line tool. May be the result of executing an expression, such as building a configuration file from a template.

Fields

field

required

type

description

entry

required

If the value is a string literal or an expression which evaluates to a string, a new file must be created with the string as the file contents.

If the value is an expression that evaluates to a File object, this indicates the referenced file should be added to the designated output directory prior to executing the tool.

If the value is an expression that evaluates to a Dirent object, this indicates that the File or Directory in entry should be added to the designated output directory with the name in entryname.

If writable is false, the file may be made available using a bind mount or file system link to avoid unnecessary copying of the input file.

entryname

field

required

type

description

inputs

required

array<InputParameter> |
map<id, type | InputParameter>

outputs

required

array<ExpressionToolOutputParameter> |
map<id, type | ExpressionToolOutputParameter>

Defines the parameters representing the output of the process. May be used to generate and/or validate the output object.

class

required

expression

required

The expression to execute. The expression must return a JSON object which matches the output parameters of the ExpressionTool.

id

optional

The unique identifier for this process object.

requirements

optional

hints

optional

array<Any> | map<class, Any>

label

optional

A short, human-readable label of this process object.

doc

optional

A long, human-readable description of this process object.

cwlVersion

optional

CWLVersion

CWL document version. Always required at the document root. Not required for a Process embedded inside another Process.

4.2.13.1 InputParameter §

Fields

field

required

type

description

id

required

The unique identifier for this parameter object.

label

optional

A short, human-readable label of this object.

secondaryFiles

optional

string | Expression | array<string | Expression>

Only valid when type: File or is an array of items: File.

If string begins with one or more caret ^ characters, for each caret, remove the last file extension from the path (the last period . and all following characters). If there are no file extensions, the path is unchanged.
Append the remainder of the string to the end of the file path.

streamable

optional

Only valid when type: File or is an array of items: File.

doc

optional

string | array<string>

A documentation string for this type, or an array of strings which should be concatenated.

format

optional

string | array<string> | Expression

Only valid when type: File or is an array of items: File.

This must be one or more IRIs of concept nodes that represents file formats which are allowed as input to this parameter, preferrably defined within an ontology. If no ontology is available, file formats may be tested by exact match.

inputBinding

optional

Describes how to handle the inputs of a process and convert them into a concrete form for execution, such as command line parameters.

default

optional

Any

The default value to use for this parameter if the parameter is missing from the input object, or if the value of the parameter in the input object is null. Default values are applied before evaluating expressions (e.g. dependent valueFrom fields).

type

optional

Specify valid types of data that may be assigned to this parameter.

4.2.13.2 ExpressionToolOutputParameter §

Fields

field

required

type

description

id

required

The unique identifier for this parameter object.

label

optional

A short, human-readable label of this object.

secondaryFiles

optional

string | Expression | array<string | Expression>

Only valid when type: File or is an array of items: File.

If string begins with one or more caret ^ characters, for each caret, remove the last file extension from the path (the last period . and all following characters). If there are no file extensions, the path is unchanged.
Append the remainder of the string to the end of the file path.

streamable

optional

Only valid when type: File or is an array of items: File.

doc

optional

string | array<string>

A documentation string for this type, or an array of strings which should be concatenated.

outputBinding

optional

Describes how to handle the outputs of a process.

format

optional