Common Workflow Language (CWL) Workflow Description, v1.1 §

This version:

Current version:

Authors:

Contributors:

This specification was approved on 6 June 2019 by the CWL leadership team consisting of:

Abstract §

One way to define a workflow is: an analysis task represented by a directed graph describing a sequence of operations that transform an input data set to output. This specification defines the Common Workflow Language (CWL) Workflow description, a vendor-neutral standard for representing workflows intended to be portable across a variety of computing platforms.

Status of this document §

This document is the product of the Common Workflow Language working group. The source for the latest stable version of this document is available in the "v1.0" directory at

https://github.com/common-workflow-language/common-workflow-language

The current development version is at https://github.com/common-workflow-language/cwl-v1.1/

The products of the CWL working group (including this document) are made available under the terms of the Apache License, version 2.0.

Table of contents

1. Introduction §

The Common Workflow Language (CWL) working group is an informal, multi-vendor working group consisting of various organizations and individuals that have an interest in portability of data analysis workflows. The goal is to create specifications like this one that enable data scientists to describe analysis tools and workflows that are powerful, easy to use, portable, and support reproducibility.

1.1 Introduction to CWL Workflow standard v1.1 §

This specification represents the latest stable release from the CWL group. Since the v1.0 release, v1.1 introduces the following updates to the CWL Workflow standard. Documents should to use cwlVersion: v1.1 to make use of new syntax and features introduced in v1.1. Existing v1.0 documents should be trivially updatable by changing cwlVersion, however CWL documents that relied on previously undefined or underspecified behavior may have slightly different behavior in v1.1.

1.2 Changelog §

  • Clarify intent of ExpressionTool and clarify that they can be run standalone.
  • Clarify how Requirements are inherited by step processes.
  • Clarify behavior around step inputs not consumed by the target run process.
  • Document explicitly that CWL allows pass-through of workflow inputs to outputs.
  • Added optional name and doc fields to OutputRecordSchema.
  • Default values for some fields are now expressed in the schema.
  • When defining record types, fields of type File may now include format, secondaryFiles, and streamable.
  • The Input schemas (Record, Array, Enum), now permits a doc field.
  • Any doc field may be an array of strings in addition to the previously allowed single string.
  • The run field now introduces a subscope so that embedded definitions do not have identifier conflicts with the outer workflow.
  • Workflow.inputs and ExpressionTool.inputs now refer to the type WorkflowInputParameter instead of InputParameter; the only syntax difference from v1.0 is that inputBinding is now deprecated (as there is no command line to bind input values to) and inputBinding in a Workflow context will be removed in v2.0. Use the new WorkflowInputParameter.loadContents instead.
  • The presence of OutputRecordField.outputBinding in v1.0 was due to a technical error and as it makes no semantic sense it was removed.
  • WorkflowStepInput now has a label field.
  • Addition of cwl:requirements field to input object documents.
  • secondaryFiles can now be explicitly marked as required or not.
  • Add note that undefined details related to execution are left open to the platform.
  • Added WorkReuse feature, allowing to enable or disable the reuse behavior for a particular tool or step for implementations that support reusing output from past work.
  • Added NetworkAccess feature, allowing to indicate whether a process requires outgoing network access.
  • Added InplaceUpdateRequirement feature, allowing tools to directly update files with writable: true in InitialWorkDirRequirement.
  • Added LoadListingRequirement and loadListing to control whether and how Directory listings should be loaded for use in expressions.
  • Better explain the map<…> notation that has existed since v1.0.
  • Fixed schema error where the type field inside the inputs and outputs fields for both Workflow and ExpressionTool was incorrectly listed as optional.
  • For multi-Process CWL documents, if no particular process is named then the process with the id of #main is chosen.
  • Made explicit that the $namespaces of the top level CWL document are also available to the input object as well.
  • Fields with type "Expression" no longer include "string" in the type union unless a string is semantically valid. Where a bare string is not semantically valid, these fields must contain either a non-string value accepted by the field type, or a valid expression which returns a value having one of the the other types defined for that field.
  • WorkflowStepInput now has a loadContents field.
  • WorkflowStepInput.id field value does not have to match an input.id value from the process specified in the run field.
  • 2021-11-22 Errata: Fixed $schema typo. It is $schemas (plural).

See also the CWL Command Line Tool Description, v1.1 changelog.

1.3 Purpose §

The Common Workflow Language Command Line Tool Description express workflows for data-intensive science, such as Bioinformatics, Chemistry, Physics, and Astronomy. This specification is intended to define a data and execution model for Workflows that can be implemented on top of a variety of computing platforms, ranging from an individual workstation to cluster, grid, cloud, and high performance computing systems. Details related to execution of these workflow not laid out in this specification are open to interpretation by the computing platform implementing this specification.

1.4 References to other specifications §

Javascript Object Notation (JSON): http://json.org

JSON Linked Data (JSON-LD): http://json-ld.org

YAML: http://yaml.org

Avro: https://avro.apache.org/docs/1.8.1/spec.html

Uniform Resource Identifier (URI) Generic Syntax: https://tools.ietf.org/html/rfc3986)

Internationalized Resource Identifiers (IRIs): https://tools.ietf.org/html/rfc3987

Portable Operating System Interface (POSIX.1-2008): http://pubs.opengroup.org/onlinepubs/9699919799/

Resource Description Framework (RDF): http://www.w3.org/RDF/

XDG Base Directory Specification: https://specifications.freedesktop.org/basedir-spec/basedir-spec-0.6.html

1.5 Scope §

This document describes CWL syntax, execution, and object model. It is not intended to document a CWL specific implementation, however it may serve as a reference for the behavior of conforming implementations.

1.6 Terminology §

The terminology used to describe CWL documents is defined in the Concepts section of the specification. The terms defined in the following list are used in building those definitions and in describing the actions of a CWL implementation:

may: Conforming CWL documents and CWL implementations are permitted but not required to behave as described.

must: Conforming CWL documents and CWL implementations are required to behave as described; otherwise they are in error.

error: A violation of the rules of this specification; results are undefined. Conforming implementations may detect and report an error and may recover from it.

fatal error: A violation of the rules of this specification; results are undefined. Conforming implementations must not continue to execute the current process and may report an error.

at user option: Conforming software may or must (depending on the modal verb in the sentence) behave as described; if it does, it must provide users a means to enable or disable the behavior described.

deprecated: Conforming software may implement a behavior for backwards compatibility. Portable CWL documents should not rely on deprecated behavior. Behavior marked as deprecated may be removed entirely from future revisions of the CWL specification.

2. Data model §

2.1 Data concepts §

An object is a data structure equivalent to the "object" type in JSON, consisting of a unordered set of name/value pairs (referred to here as fields) and where the name is a string and the value is a string, number, boolean, array, or object.

A document is a file containing a serialized object, or an array of objects.

A process is a basic unit of computation which accepts input data, performs some computation, and produces output data. Examples include CommandLineTools, Workflows, and ExpressionTools.

An input object is an object describing the inputs to an invocation of a process.

An output object is an object describing the output resulting from an invocation of a process.

An input schema describes the valid format (required fields, data types) for an input object.

An output schema describes the valid format for an output object.

Metadata is information about workflows, tools, or input items.

2.2 Syntax §

CWL documents must consist of an object or array of objects represented using JSON or YAML syntax. Upon loading, a CWL implementation must apply the preprocessing steps described in the Semantic Annotations for Linked Avro Data (SALAD) Specification. An implementation may formally validate the structure of a CWL document using SALAD schemas located at https://github.com/common-workflow-language/cwl-v1.1/

2.2.1 map §

Note: This section is non-normative.

type: array<ComplexType> | map<key_field, ComplexType>

The above syntax in the CWL specifications means there are two or more ways to write the given value.

Option one is a array and is the most verbose option.

Option one generic example:

some_cwl_field:
  - key_field: a_complex_type1
    field2: foo
    field3: bar
  - key_field: a_complex_type2
    field2: foo2
    field3: bar2
  - key_field: a_complex_type3

Option one specific example using Workflow.inputs:

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

inputs:
  - id: workflow_input01
    type: string
  - id: workflow_input02
    type: File
    format: http://edamontology.org/format_2572

Option two is enabled by the map<…> syntax. Instead of an array of entries we use a mapping, where one field of the ComplexType (here named key_field) becomes the key in the map, and its value is the rest of the ComplexType without the key field. If all of the other fields of the ComplexType are optional and unneeded, then we can indicate this with an empty mapping as the value: a_complex_type3: {}

Option two generic example:

some_cwl_field:
  a_complex_type1:  # this was the "key_field" from above
    field2: foo
    field3: bar
  a_complex_type2:
    field2: foo2
    field3: bar2
  a_complex_type3: {}  # we accept the defualt values for "field2" and "field3"

Option two specific example using Workflow.inputs:

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

inputs:
  workflow_input01:
    type: string
  workflow_input02:
    type: File
    format: http://edamontology.org/format_2572

Option two specific example using SoftwareRequirement.packages:

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

hints:
  SoftwareRequirement:
    packages:
      sourmash:
        specs: [ https://doi.org/10.21105/joss.00027 ]
      screed:
        version: [ "1.0" ]
      python: {}

` Sometimes we have a third and even more compact option denoted like this:

type: array<ComplexType> | map<key_field, field2 | ComplexType>

For this example, if we only need the key_field and field2 when specifying our ComplexTypes (because the other fields are optional and we are fine with their default values) then we can abbreviate.

Option three generic example:

some_cwl_field:
  a_complex_type1: foo   # we accept the default value for field3
  a_complex_type2: foo2  # we accept the default value for field3
  a_complex_type3: {}    # we accept the default values for "field2" and "field3"

Option three specific example using Workflow.inputs:

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

inputs:
  workflow_input01: string
  workflow_input02: File  # we accept the default of no File format

Option three specific example using SoftwareRequirement.packages:

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

hints:
  SoftwareRequirement:
    packages:
      sourmash: [ https://doi.org/10.21105/joss.00027 ]
      python: {}

What if some entries we want to mix the option 2 and 3? You can!

Mixed option 2 and 3 generic example:

some_cwl_field:
  my_complex_type1: foo   # we accept the default value for field3
  my_complex_type2:
    field2: foo2
    field3: bar2          # we did not accept the default value for field3
                          # so we had to use the slightly expanded syntax
  my_complex_type3: {}    # as before, we accept the default values for both
                          # "field2" and "field3"

Mixed option 2 and 3 specific example using Workflow.inputs:

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

inputs:
  workflow_input01: string
  workflow_input02:     # we use the longer way
    type: File          # because we want to specify the "format" too
    format: http://edamontology.org/format_2572

Mixed option 2 and 3 specific example using SoftwareRequirement.packages:

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

hints:
  SoftwareRequirement:
    packages:
      sourmash: [ https://doi.org/10.21105/joss.00027 ]
      screed:
        specs: [ https://github.com/dib-lab/screed ]
        version: [ "1.0" ]
      python: {}

Note: The map<…> (compact) versions are optional for users, the verbose option #1 is always allowed, but for presentation reasons option 3 and 2 may be preferred by human readers. Consumers of CWL must support all three options.

The normative explanation for these variations, aimed at implementors, is in the Schema Salad specification.

2.3 Identifiers §

If an object contains an id field, that is used to uniquely identify the object in that document. The value of the id field must be unique over the entire document. Identifiers may be resolved relative to either the document base and/or other identifiers following the rules are described in the Schema Salad specification.

An implementation may choose to only honor references to object types for which the id field is explicitly listed in this specification.

2.4 Document preprocessing §

An implementation must resolve $import and $include directives as described in the Schema Salad specification.

Another transformation defined in Schema salad is simplification of data type definitions. Type <T> ending with ? should be transformed to [<T>, "null"]. Type <T> ending with [] should be transformed to {"type": "array", "items": <T>}

2.5 Extensions and metadata §

Input metadata (for example, a sample identifier) may be represented within a tool or workflow using input parameters which are explicitly propagated to output. Future versions of this specification may define additional facilities for working with input/output metadata.

Implementation extensions not required for correct execution (for example, fields related to GUI presentation) and metadata about the tool or workflow itself (for example, authorship for use in citations) may be provided as additional fields on any object. Such extensions fields must use a namespace prefix listed in the $namespaces section of the document as described in the Schema Salad specification.

It is recommended that concepts from schema.org are used whenever possible. For the $schemas field we recommend their RDF encoding: https://schema.org/version/latest/schemaorg-current-https.rdf

Implementation extensions which modify execution semantics must be listed in the requirements field.

3. Execution model §

3.1 Execution concepts §

A parameter is a named symbolic input or output of process, with an associated datatype or schema. During execution, values are assigned to parameters to make the input object or output object used for concrete process invocation.

A CommandLineTool is a process characterized by the execution of a standalone, non-interactive program which is invoked on some input, produces output, and then terminates.

A workflow is a process characterized by multiple subprocess steps, where step outputs are connected to the inputs of downstream steps to form a directed acylic graph, and independent steps may run concurrently.

A runtime environment is the actual hardware and software environment when executing a command line tool. It includes, but is not limited to, the hardware architecture, hardware resources, operating system, software runtime (if applicable, such as the specific Python interpreter or the specific Java virtual machine), libraries, modules, packages, utilities, and data files required to run the tool.

A workflow platform is a specific hardware and software implementation capable of interpreting CWL documents and executing the processes specified by the document. The responsibilities of the workflow platform may include scheduling process invocation, setting up the necessary runtime environment, making input data available, invoking the tool process, and collecting output.

A workflow platform may choose to only implement the Command Line Tool Description part of the CWL specification.

It is intended that the workflow platform has broad leeway outside of this specification to optimize use of computing resources and enforce policies not covered by this specification. Some areas that are currently out of scope for CWL specification but may be handled by a specific workflow platform include:

  • Data security and permissions
  • Scheduling tool invocations on remote cluster or cloud compute nodes.
  • Using virtual machines or operating system containers to manage the runtime (except as described in DockerRequirement).
  • Using remote or distributed file systems to manage input and output files.
  • Transforming file paths.
  • Pausing, resuming or checkpointing processes or workflows.

Conforming CWL processes must not assume anything about the runtime environment or workflow platform unless explicitly declared though the use of process requirements.

3.2 Generic execution process §

The generic execution sequence of a CWL process (including workflows and command line line tools) is as follows.

  1. Load input object.
  2. Load, process and validate a CWL document, yielding one or more process objects. The $namespaces present in the CWL document are also used when validating and processing the input object.
  3. If there are multiple process objects (due to $graph) and which process object to start with is not specified in the input object (via a cwl:tool entry) or by any other means (like a URL fragment) then choose the process with the id of "#main" or "main".
  4. Validate the input object against the inputs schema for the process.
  5. Validate process requirements are met.
  6. Perform any further setup required by the specific process type.
  7. Execute the process.
  8. Capture results of process execution into the output object.
  9. Validate the output object against the outputs schema for the process.
  10. Report the output object to the process caller.

3.3 Requirements and hints §

A process requirement modifies the semantics or runtime environment of a 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.

A hint is similar to a requirement; however, it is not an error if an implementation cannot satisfy all hints. The implementation may report a warning if a hint cannot be satisfied.

Optionally, implementations may allow requirements to be specified in the input object document as an array of requirements under the field name cwl:requirements. If implementations allow this, then such requirements should be combined with any requirements present in the corresponding Process as if they were specified there.

Requirements specified in a parent Workflow are inherited by step processes if they are valid for that step. If the substep is a CommandLineTool only the InlineJavascriptRequirement, SchemaDefRequirement, DockerRequirement, SoftwareRequirement, InitialWorkDirRequirement, EnvVarRequirement, ShellCommandRequirement, ResourceRequirement are valid.

As good practice, it is best to have process requirements be self-contained, such that each process can run successfully by itself.

If the same process requirement appears at different levels of the workflow, the most specific instance of the requirement is used, that is, an entry in requirements on a process implementation such as CommandLineTool will take precedence over an entry in requirements specified in a workflow step, and an entry in requirements on a workflow step takes precedence over the workflow. Entries in hints are resolved the same way.

Requirements override hints. If a process implementation provides a process requirement in hints which is also provided in requirements by an enclosing workflow or workflow step, the enclosing requirements takes precedence.

3.4 Parameter references §

Parameter references are denoted by the syntax $(...) and may be used in any field permitting the pseudo-type Expression, as specified by this document. Conforming implementations must support parameter references. Parameter references use the following subset of Javascript/ECMAScript 5.1 syntax, but they are designed to not require a Javascript engine for evaluation.

In the following BNF grammar, character classes, and grammar rules are denoted in '{}', '-' denotes exclusion from a character class, '(())' denotes grouping, '|' denotes alternates, trailing '*' denotes zero or more repeats, '+' denote one or more repeats, '/' escapes these special characters, and all other characters are literal values.

symbol:: {Unicode alphanumeric}+
singleq:: [' (( {character - '} | \' ))* ']
doubleq:: [" (( {character - "} | \" ))* "]
index:: [ {decimal digit}+ ]
segment:: . {symbol} | {singleq} | {doubleq} | {index}
parameter reference::$( {symbol} {segment}*)

Use the following algorithm to resolve a parameter reference:

  1. Match the leading symbol as the key
  2. Look up the key in the parameter context (described below) to get the current value. It is an error if the key is not found in the parameter context.
  3. If there are no subsequent segments, terminate and return current value
  4. Else, match the next segment
  5. Extract the symbol, string, or index from the segment as the key
  6. Look up the key in current value and assign as new current value. If the key is a symbol or string, the current value must be an object. If the key is an index, the current value must be an array or string. It is an error if the key does not match the required type, or the key is not found or out of range.
  7. Repeat steps 3-6

The root namespace is the parameter context. The following parameters must be provided:

  • inputs: The input object to the current Process.
  • self: A context-specific value. The contextual values for 'self' are documented for specific fields elsewhere in this specification. If a contextual value of 'self' is not documented for a field, it must be 'null'.
  • runtime: An object containing configuration details. Specific to the process type. An implementation may provide opaque strings for any or all fields of runtime. These must be filled in by the platform after processing the Tool but before actual execution. Parameter references and expressions may only use the literal string value of the field and must not perform computation on the contents, except where noted otherwise.

If the value of a field has no leading or trailing non-whitespace characters around a parameter reference, the effective value of the field becomes the value of the referenced parameter, preserving the return type.

If the value of a field has non-whitespace leading or trailing characters around a parameter reference, it is subject to string interpolation. The effective value of the field is a string containing the leading characters, followed by the string value of the parameter reference, followed by the trailing characters. The string value of the parameter reference is its textual JSON representation with the following rules:

  • Leading and trailing quotes are stripped from strings
  • Objects entries are sorted by key

Multiple parameter references may appear in a single field. This case must be treated as a string interpolation. After interpolating the first parameter reference, interpolation must be recursively applied to the trailing characters to yield the final string value.

3.5 Expressions (Optional) §

An expression is a fragment of Javascript/ECMAScript 5.1 code evaluated by the workflow platform to affect the inputs, outputs, or behavior of a process. In the generic execution sequence, expressions may be evaluated during step 5 (process setup), step 6 (execute process), and/or step 7 (capture output). Expressions are distinct from regular processes in that they are intended to modify the behavior of the workflow itself rather than perform the primary work of the workflow.

Expressions in CWL are an optional feature and are not required to be implemented by all consumers of CWL documents. They should be used sparingly, when there is no other way to achieve the desired outcome. Excessive use of expressions may be a signal that other refactoring of the tools or workflows would benefit the author, runtime, and users of the CWL document in question.

To declare the use of expressions, the document must include the process requirement InlineJavascriptRequirement. Expressions may be used in any field permitting the pseudo-type Expression, as specified by this document.

Expressions are denoted by the syntax $(...) or ${...}. A code fragment wrapped in the $(...) syntax must be evaluated as a ECMAScript expression. A code fragment wrapped in the ${...} syntax must be evaluated as a ECMAScript function body for an anonymous, zero-argument function. Expressions must return a valid JSON data type: one of null, string, number, boolean, array, object. Other return values must result in a permanentFailure. Implementations must permit any syntactically valid Javascript and account for nesting of parenthesis or braces and that strings that may contain parenthesis or braces when scanning for expressions.

The runtime must include any code defined in the "expressionLib" field of InlineJavascriptRequirement prior to executing the actual expression.

Before executing the expression, the runtime must initialize as global variables the fields of the parameter context described above.

The effective value of the field after expression evaluation follows the same rules as parameter references discussed above. Multiple expressions may appear in a single field.

Expressions must be evaluated in an isolated context (a "sandbox") which permits no side effects to leak outside the context. Expressions also must be evaluated in Javascript strict mode.

The order in which expressions are evaluated is undefined except where otherwise noted in this document.

An implementation may choose to implement parameter references by evaluating as a Javascript expression. The results of evaluating parameter references must be identical whether implemented by Javascript evaluation or some other means.

Implementations may apply other limits, such as process isolation, timeouts, and operating system containers/jails to minimize the security risks associated with running untrusted code embedded in a CWL document.

Javascript exceptions thrown from a CWL expression must result in a permanentFailure of the CWL process.

3.6 Executing CWL documents as scripts §

By convention, a CWL document may begin with #!/usr/bin/env cwl-runner and be marked as executable (the POSIX "+x" permission bits) to enable it to be executed directly. A workflow platform may support this mode of operation; if so, it must provide cwl-runner as an alias for the platform's CWL implementation.

A CWL input object document may similarly begin with #!/usr/bin/env cwl-runner and be marked as executable. In this case, the input object must include the field cwl:tool supplying an IRI to the default CWL document that should be executed using the fields of the input object as input parameters.

The cwl-runner interface is required for conformance testing and is documented in cwl-runner.cwl.

3.7 Discovering CWL documents on a local filesystem §

To discover CWL documents look in the following locations:

For each value in the XDG_DATA_DIRS environment variable (which is a : colon separated list), check the ./commonwl subdirectory. If XDG_DATA_DIRS is unset or empty, then check using the default value for XDG_DATA_DIRS: /usr/local/share/:/usr/share/ (That is to say, check /usr/share/commonwl/ and /usr/local/share/commonwl/)

Then check $XDG_DATA_HOME/commonwl/.

If the XDG_DATA_HOME environment variable is unset, its default value is $HOME/.local/share (That is to say, check $HOME/.local/share/commonwl)

$XDG_DATA_HOME and $XDG_DATA_DIRS are from the XDG Base Directory Specification

4. Workflow §

A workflow describes a set of steps and the dependencies between those steps. When a step produces output that will be consumed by a second step, the first step is a dependency of the second step.

When there is a dependency, the workflow engine must execute the preceding step and wait for it to successfully produce output before executing the dependent step. If two steps are defined in the workflow graph that are not directly or indirectly dependent, these steps are independent, and may execute in any order or execute concurrently. A workflow is complete when all steps have been executed.

Dependencies between parameters are expressed using the source field on workflow step input parameters and workflow output parameters.

The source field expresses the dependency of one parameter on another such that when a value is associated with the parameter specified by source, that value is propagated to the destination parameter. When all data links inbound to a given step are fufilled, the step is ready to execute.

Workflow success and failure §

A completed step must result in one of success, temporaryFailure or permanentFailure states. An implementation may choose to retry a step execution which resulted in temporaryFailure. An implementation may choose to either continue running other steps of a workflow, or terminate immediately upon permanentFailure.

  • If any step of a workflow execution results in permanentFailure, then the workflow status is permanentFailure.

  • If one or more steps result in temporaryFailure and all other steps complete success or are not executed, then the workflow status is temporaryFailure.

  • If all workflow steps are executed and complete with success, then the workflow status is success.

Extensions §

ScatterFeatureRequirement and SubworkflowFeatureRequirement are available as standard extensions to core workflow semantics.

Fields

field
required
type
description
inputs
required
array<WorkflowInputParameter> |
map<id, type | WorkflowInputParameter>

Defines the input parameters of the process. 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 to build a user interface for constructing the input object.

When accepting an input object, all input parameters must have a value. If an input parameter is missing from the input object, it must be assigned a value of null (or the value of default for that parameter, if provided) for the purposes of validation and evaluation of expressions.

outputs
required
array<WorkflowOutputParameter> |
map<id, type | WorkflowOutputParameter>

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

class
required
string
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
string

The unique identifier for this object.

label
optional
string

A short, human-readable label of this object.

doc
optional
string | array<string>

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

requirements
optional
array<InlineJavascriptRequirement | SchemaDefRequirement | LoadListingRequirement | DockerRequirement | SoftwareRequirement | InitialWorkDirRequirement | EnvVarRequirement | ShellCommandRequirement | ResourceRequirement | WorkReuse | NetworkAccess | InplaceUpdateRequirement | ToolTimeLimit | SubworkflowFeatureRequirement | ScatterFeatureRequirement | MultipleInputFeatureRequirement | StepInputExpressionRequirement> |
map<class, InlineJavascriptRequirement | SchemaDefRequirement | LoadListingRequirement | DockerRequirement | SoftwareRequirement | InitialWorkDirRequirement | EnvVarRequirement | ShellCommandRequirement | ResourceRequirement | WorkReuse | NetworkAccess | InplaceUpdateRequirement | ToolTimeLimit | SubworkflowFeatureRequirement | ScatterFeatureRequirement | MultipleInputFeatureRequirement | StepInputExpressionRequirement>

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.

cwlVersion
optional
CWLVersion

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

4.1 WorkflowInputParameter §

Fields

field
required
type
description
type
required
CWLType | InputRecordSchema | InputEnumSchema | InputArraySchema | string | array<CWLType | InputRecordSchema | InputEnumSchema | InputArraySchema | string>

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

label
optional
string

A short, human-readable label of this object.

secondaryFiles
optional
SecondaryFileSchema | array<SecondaryFileSchema>

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

Provides a pattern or expression specifying files or directories that should be included alongside the primary file. Secondary files may be required or optional. When not explicitly specified, secondary files specified for inputs are required and outputs are optional. An implementation must include matching Files and Directories in the secondaryFiles property of the primary file. These Files and Directories must be transferred and staged alongside the primary file. An implementation may fail workflow execution if a required 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. The expression may return "null" in which case there is no secondaryFile from that expression.

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:

  1. If string ends with ? character, remove the last ? and mark the resulting secondary file as optional.
  2. 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.
  3. Append the remainder of the string to the end of the file path.
streamable
optional
boolean

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 object, or an array of strings which should be concatenated.

id
optional
string

The unique identifier for this object.

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.

loadContents
optional
boolean

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.

loadListing
optional
LoadListingEnum

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

Specify the desired behavior for loading the listing field of a Directory object for use by expressions.

The order of precedence for loadListing is:

  1. loadListing on an individual parameter
  2. Inherited from LoadListingRequirement
  3. By default: no_listing
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).

inputBinding
optional
InputBinding

Deprecated. Preserved for v1.0 backwards compatability. Will be removed in CWL v2.0. Use WorkflowInputParameter.loadContents instead.

4.1.1 SecondaryFileSchema §

Fields

field
required
type
description
pattern
required
string | Expression

Provides a pattern or expression specifying files or directories that should be included alongside the primary file.

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. The expression may return "null" in which case there is no secondaryFile from that expression.

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:

  1. If string ends with ? character, remove the last ? and mark the resulting secondary file as optional.
  2. 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.
  3. Append the remainder of the string to the end of the file path.
required
optional
boolean | Expression

An implementation must not fail workflow execution if required is set to false and the expected secondary file does not exist. Default value for required field is true for secondary files on input and false for secondary files on output.

4.1.2 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

symboldescription
ExpressionPlaceholder

4.1.3 LoadListingEnum §

Specify the desired behavior for loading the listing field of a Directory object for use by expressions.

Symbols

symboldescription
no_listing Do not load the directory listing.
shallow_listing Only load the top level listing, do not recurse into subdirectories.
deep_listing Load the directory listing and recursively load all subdirectories as well.

4.1.4 Any §

The Any type validates for any non-null value.

Symbols

symboldescription
Any

4.1.5 CWLType §

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

Symbols

symboldescription
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.6 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
string

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
string

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
string

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
string

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
string

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
string

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
string

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
string

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
string

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.6.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
string

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
string

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.

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
string

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 /.

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.

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.7 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
string

A short, human-readable label of this object.

doc
optional
string | array<string>

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

name
optional
string

The identifier for this type

4.1.8 InputRecordField §

Fields

field
required
type
description
name
required
string

The name of the field

type
required
CWLType | InputRecordSchema | InputEnumSchema | InputArraySchema | string | array<CWLType | InputRecordSchema | InputEnumSchema | InputArraySchema | string>

The field type

doc
optional
string | array<string>

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

label
optional
string

A short, human-readable label of this object.

secondaryFiles
optional
SecondaryFileSchema | array<SecondaryFileSchema>

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

Provides a pattern or expression specifying files or directories that should be included alongside the primary file. Secondary files may be required or optional. When not explicitly specified, secondary files specified for inputs are required and outputs are optional. An implementation must include matching Files and Directories in the secondaryFiles property of the primary file. These Files and Directories must be transferred and staged alongside the primary file. An implementation may fail workflow execution if a required 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. The expression may return "null" in which case there is no secondaryFile from that expression.

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:

  1. If string ends with ? character, remove the last ? and mark the resulting secondary file as optional.
  2. 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.
  3. Append the remainder of the string to the end of the file path.
streamable
optional
boolean

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.

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.

loadContents
optional
boolean

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.

loadListing
optional
LoadListingEnum

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

Specify the desired behavior for loading the listing field of a Directory object for use by expressions.

The order of precedence for loadListing is:

  1. loadListing on an individual parameter
  2. Inherited from LoadListingRequirement
  3. By default: no_listing

4.1.8.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
string

A short, human-readable label of this object.

doc
optional
string | array<string>

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

name
optional
string

The identifier for this type

4.1.8.2 InputArraySchema §

Fields

field
required
type
description
items
required
CWLType | InputRecordSchema | InputEnumSchema | InputArraySchema | string | array<CWLType | InputRecordSchema | InputEnumSchema | InputArraySchema | string>

Defines the type of the array elements.

type
required
constant value array

Must be array

label
optional
string

A short, human-readable label of this object.

doc
optional
string | array<string>

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

name
optional
string

The identifier for this type

4.1.9 InputBinding §

Fields

field
required
type
description
loadContents
optional
boolean

Use of loadContents in InputBinding is deprecated. Preserved for v1.0 backwards compatability. Will be removed in CWL v2.0. Use InputParameter.loadContents instead.

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.

4.2 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. It is legal to connect a WorkflowInputParameter to a WorkflowOutputParameter.

Fields

field
required
type
description
type
required
CWLType | OutputRecordSchema | OutputEnumSchema | OutputArraySchema | string | array<CWLType | OutputRecordSchema | OutputEnumSchema | OutputArraySchema | string>

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

label
optional
string

A short, human-readable label of this object.

secondaryFiles
optional
SecondaryFileSchema | array<SecondaryFileSchema>

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

Provides a pattern or expression specifying files or directories that should be included alongside the primary file. Secondary files may be required or optional. When not explicitly specified, secondary files specified for inputs are required and outputs are optional. An implementation must include matching Files and Directories in the secondaryFiles property of the primary file. These Files and Directories must be transferred and staged alongside the primary file. An implementation may fail workflow execution if a required 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. The expression may return "null" in which case there is no secondaryFile from that expression.

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:

  1. If string ends with ? character, remove the last ? and mark the resulting secondary file as optional.
  2. 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.
  3. Append the remainder of the string to the end of the file path.
streamable
optional
boolean

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 object, or an array of strings which should be concatenated.

id
optional
string

The unique identifier for this object.

format
optional
string | Expression

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

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

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".

4.2.1 LinkMergeMethod §

The input link merge method, described in WorkflowStepInput.

Symbols

symboldescription
merge_nested
merge_flattened

4.2.2 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
string

A short, human-readable label of this object.

doc
optional
string | array<string>

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

name
optional
string

The identifier for this type

4.2.3 OutputRecordField §

Fields

field
required
type
description
name
required
string

The name of the field

type
required
CWLType | OutputRecordSchema | OutputEnumSchema | OutputArraySchema | string | array<CWLType | OutputRecordSchema | OutputEnumSchema | OutputArraySchema | string>

The field type

doc
optional
string | array<string>

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

label
optional
string

A short, human-readable label of this object.

secondaryFiles
optional
SecondaryFileSchema | array<SecondaryFileSchema>

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

Provides a pattern or expression specifying files or directories that should be included alongside the primary file. Secondary files may be required or optional. When not explicitly specified, secondary files specified for inputs are required and outputs are optional. An implementation must include matching Files and Directories in the secondaryFiles property of the primary file. These Files and Directories must be transferred and staged alongside the primary file. An implementation may fail workflow execution if a required 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. The expression may return "null" in which case there is no secondaryFile from that expression.

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:

  1. If string ends with ? character, remove the last ? and mark the resulting secondary file as optional.
  2. 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.
  3. Append the remainder of the string to the end of the file path.
streamable
optional
boolean

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.

format
optional
string | Expression

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

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

4.2.3.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
string

A short, human-readable label of this object.

doc
optional
string | array<string>

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

name
optional
string

The identifier for this type

4.2.3.2 OutputArraySchema §

Fields

field
required
type
description
items
required
CWLType | OutputRecordSchema | OutputEnumSchema | OutputArraySchema | string | array<CWLType | OutputRecordSchema | OutputEnumSchema | OutputArraySchema | string>

Defines the type of the array elements.

type
required
constant value array

Must be array

label
optional
string

A short, human-readable label of this object.

doc
optional
string | array<string>

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

name
optional
string

The identifier for this type

4.3 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
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.

id
optional
string

The unique identifier for this object.

label
optional
string

A short, human-readable label of this object.

doc
optional
string | array<string>

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

requirements
optional
array<InlineJavascriptRequirement | SchemaDefRequirement | LoadListingRequirement | DockerRequirement | SoftwareRequirement | InitialWorkDirRequirement | EnvVarRequirement | ShellCommandRequirement | ResourceRequirement | WorkReuse | NetworkAccess | InplaceUpdateRequirement | ToolTimeLimit | SubworkflowFeatureRequirement | ScatterFeatureRequirement | MultipleInputFeatureRequirement | StepInputExpressionRequirement> |
map<class, InlineJavascriptRequirement | SchemaDefRequirement | LoadListingRequirement | DockerRequirement | SoftwareRequirement | InitialWorkDirRequirement | EnvVarRequirement | ShellCommandRequirement | ResourceRequirement | WorkReuse | NetworkAccess | InplaceUpdateRequirement | ToolTimeLimit | SubworkflowFeatureRequirement | ScatterFeatureRequirement | MultipleInputFeatureRequirement | StepInputExpressionRequirement>

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.

scatter
optional
string | array<string>
scatterMethod
optional
ScatterMethod

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

4.3.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 process specified by the run field. Only input parameters declared by the target process will be passed through at runtime to the process though additonal parameters may be specified (for use within valueFrom expressions for instance) - unconnected or unused parameters do not represent an error condition.

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
optional
string

The unique identifier for this object.

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".

loadContents
optional
boolean

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.

loadListing
optional
LoadListingEnum

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

Specify the desired behavior for loading the listing field of a Directory object for use by expressions.

The order of precedence for loadListing is:

  1. loadListing on an individual parameter
  2. Inherited from LoadListingRequirement
  3. By default: no_listing
label
optional
string

A short, human-readable label of this object.

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
string | Expression

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.

  1. null if there is no source field
  2. 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.
  3. 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.3.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.

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.

Fields

field
required
type
description
id
optional
string

The unique identifier for this object.

4.3.3 ScatterMethod §

The scatter method, as described in workflow step scatter.

Symbols

symboldescription
dotproduct
nested_crossproduct
flat_crossproduct

4.3.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
string

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.3.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
string

Always 'SchemaDefRequirement'

types
required
array<CommandInputRecordSchema | CommandInputEnumSchema | CommandInputArraySchema>

The list of type definitions.

4.3.5.1 CommandInputRecordSchema §

Fields

field
required
type
description
type
required
constant value record

Must be record

fields
optional
array<CommandInputRecordField> |
map<name, type | CommandInputRecordField>

Defines the fields of the record.

label
optional
string

A short, human-readable label of this object.

doc
optional
string | array<string>

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

name
optional
string

The identifier for this type

inputBinding
optional
CommandLineBinding

Describes how to turn this object into command line arguments.

4.3.5.1.1 CommandInputRecordField §

Fields

field
required
type
description
name
required
string

The name of the field

type
required
CWLType | CommandInputRecordSchema | CommandInputEnumSchema | CommandInputArraySchema | string | array<CWLType | CommandInputRecordSchema | CommandInputEnumSchema | CommandInputArraySchema | string>

The field type

doc
optional
string | array<string>

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

label
optional
string

A short, human-readable label of this object.

secondaryFiles
optional
SecondaryFileSchema | array<SecondaryFileSchema>

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

Provides a pattern or expression specifying files or directories that should be included alongside the primary file. Secondary files may be required or optional. When not explicitly specified, secondary files specified for inputs are required and outputs are optional. An implementation must include matching Files and Directories in the secondaryFiles property of the primary file. These Files and Directories must be transferred and staged alongside the primary file. An implementation may fail workflow execution if a required 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. The expression may return "null" in which case there is no secondaryFile from that expression.

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:

  1. If string ends with ? character, remove the last ? and mark the resulting secondary file as optional.
  2. 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.
  3. Append the remainder of the string to the end of the file path.
streamable
optional
boolean

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.

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.

loadContents
optional
boolean

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.

loadListing
optional
LoadListingEnum

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

Specify the desired behavior for loading the listing field of a Directory object for use by expressions.

The order of precedence for loadListing is:

  1. loadListing on an individual parameter
  2. Inherited from LoadListingRequirement
  3. By default: no_listing
inputBinding
optional
CommandLineBinding

Describes how to turn this object into command line arguments.

4.3.5.1.1.1 CommandInputEnumSchema §

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
string

A short, human-readable label of this object.

doc
optional
string | array<string>

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

name
optional
string

The identifier for this type

inputBinding
optional
CommandLineBinding

Describes how to turn this object into command line arguments.

4.3.5.1.1.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
boolean

Use of loadContents in InputBinding is deprecated. Preserved for v1.0 backwards compatability. Will be removed in CWL v2.0. Use InputParameter.loadContents instead.

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 | Expression

The sorting key. Default position is 0. If the inputBinding is associated with an input parameter, then 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. Expressions must return a single value of type int or a null.

prefix
optional
string

Command line prefix to add before the value.

separate
optional
boolean

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
string

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

valueFrom
optional
string | Expression

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.

If the value of the associated input parameter is null, valueFrom is not evaluated and nothing is added to the command line.

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

shellQuote
optional
boolean

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.3.5.1.1.3 CommandInputArraySchema §

Fields

field
required
type
description
items
required
CWLType | CommandInputRecordSchema | CommandInputEnumSchema | CommandInputArraySchema | string | array<CWLType | CommandInputRecordSchema | CommandInputEnumSchema | CommandInputArraySchema | string>

Defines the type of the array elements.

type
required
constant value array

Must be array

label
optional
string

A short, human-readable label of this object.

doc
optional
string | array<string>

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

name
optional
string

The identifier for this type

inputBinding
optional
CommandLineBinding

Describes how to turn this object into command line arguments.

4.3.6 LoadListingRequirement §

Specify the desired behavior for loading the listing field of a Directory object for use by expressions.

Fields

field
required
type
description
class
required
string

Always 'LoadListingRequirement'

loadListing
optional
LoadListingEnum

4.3.7 SoftwareRequirement §

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

Fields

field
required
type
description
class
required
string

Always 'SoftwareRequirement'

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

The list of software to be configured.

4.3.8 SoftwarePackage §

Fields

field
required
type
description
package
required
string

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.3.9 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
string

InitialWorkDirRequirement

listing
required
array<null | File | array<File | Directory> | Directory | Dirent | Expression> | Expression

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: ["null", File, File[], Directory, Directory[], Dirent]}.

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.3.9.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
string | Expression

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
optional
string | Expression

The name of the file or subdirectory to create in the output directory. If entry is a File or Directory, the entryname field overrides the value of basename of the File or Directory object. Optional.

writable
optional
boolean

If true, the file or directory must be writable by the tool. Changes to the file or directory must be isolated and not visible by any other CommandLineTool process. This may be implemented by making a copy of the original file or directory. Default false (files and directories read-only by default).

A directory marked as writable: true implies that all files and subdirectories are recursively writable as well.

4.3.10 WorkReuse §

For implementations that support reusing output from past work (on the assumption that same code and same input produce same results), control whether to enable or disable the reuse behavior for a particular tool or step (to accomodate situations where that assumption is incorrect). A reused step is not executed but instead returns the same output as the original execution.

If enableReuse is not specified, correct tools should assume it is enabled by default.

Fields

field
required
type
description
class
required
string

Always 'WorkReuse'

enableReuse
required
boolean | Expression

4.3.11 NetworkAccess §

Indicate whether a process requires outgoing IPv4/IPv6 network access. Choice of IPv4 or IPv6 is implementation and site specific, correct tools must support both.

If networkAccess is false or not specified, tools must not assume network access, except for localhost (the loopback device).

If networkAccess is true, the tool must be able to make outgoing connections to network resources. Resources may be on a private subnet or the public Internet. However, implementations and sites may apply their own security policies to restrict what is accessible by the tool.

Enabling network access does not imply a publically routable IP address or the ability to accept inbound connections.

Fields

field
required
type
description
class
required
string

Always 'NetworkAccess'

networkAccess
required
boolean | Expression

4.3.12 InplaceUpdateRequirement §

If inplaceUpdate is true, then an implementation supporting this feature may permit tools to directly update files with writable: true in InitialWorkDirRequirement. That is, as an optimization, files may be destructively modified in place as opposed to copied and updated.

An implementation must ensure that only one workflow step may access a writable file at a time. It is an error if a file which is writable by one workflow step file is accessed (for reading or writing) by any other workflow step running independently. However, a file which has been updated in a previous completed step may be used as input to multiple steps, provided it is read-only in every step.

Workflow steps which modify a file must produce the modified file as output. Downstream steps which futher process the file must use the output of previous steps, and not refer to a common input (this is necessary for both ordering and correctness).

Workflow authors should provide this in the hints section. The intent of this feature is that workflows produce the same results whether or not InplaceUpdateRequirement is supported by the implementation, and this feature is primarily available as an optimization for particular environments.

Users and implementers should be aware that workflows that destructively modify inputs may not be repeatable or reproducible. In particular, enabling this feature implies that WorkReuse should not be enabled.

Fields

field
required
type
description
class
required
string

Always 'InplaceUpdateRequirement'

inplaceUpdate
required
boolean

4.3.13 ToolTimeLimit §

Set an upper limit on the execution time of a CommandLineTool. A CommandLineTool whose execution duration exceeds the time limit may be preemptively terminated and considered failed. May also be used by batch systems to make scheduling decisions. The execution duration excludes external operations, such as staging of files, pulling a docker image etc, and only counts wall-time for the execution of the command line itself.

Fields

field
required
type
description
class
required
string

Always 'ToolTimeLimit'

timelimit
required
long | Expression

The time limit, in seconds. A time limit of zero means no time limit. Negative time limits are an error.

4.3.14 SubworkflowFeatureRequirement §

Indicates that the workflow platform must support nested workflows in the run field of WorkflowStep.

Fields

field
required
type
description
class
required
string

Always 'SubworkflowFeatureRequirement'

4.3.15 ScatterFeatureRequirement §

Indicates that the workflow platform must support the scatter and scatterMethod fields of WorkflowStep.

Fields

field
required
type
description
class
required
string

Always 'ScatterFeatureRequirement'

4.3.16 MultipleInputFeatureRequirement §

Indicates that the workflow platform must support multiple inbound data links listed in the source field of WorkflowStepInput.

Fields

field
required
type
description
class
required
string

Always 'MultipleInputFeatureRequirement'

4.3.17 StepInputExpressionRequirement §

Indicate that the workflow platform must support the valueFrom field of WorkflowStepInput.

Fields

field
required
type
description
class
required
string

Always 'StepInputExpressionRequirement'

4.3.18 ExpressionTool §

An ExpressionTool is a type of Process object that can be run by itself or as a Workflow step. It executes a pure Javascript expression that has access to the same input parameters as a workflow. It is meant to be used sparingly as a way to isolate complex Javascript expressions that need to operate on input data and produce some result; perhaps just a rearrangement of the inputs. No Docker software container is required or allowed.

Fields

field
required
type
description
inputs
required
array<WorkflowInputParameter> |
map<id, type | WorkflowInputParameter>

Defines the input parameters of the process. 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 to build a user interface for constructing the input object.

When accepting an input object, all input parameters must have a value. If an input parameter is missing from the input object, it must be assigned a value of null (or the value of default for that parameter, if provided) for the purposes of validation and evaluation of expressions.

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
string
expression
required
Expression

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

id
optional
string

The unique identifier for this object.

label
optional
string

A short, human-readable label of this object.

doc
optional
string | array<string>

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

requirements
optional
array<InlineJavascriptRequirement | SchemaDefRequirement | LoadListingRequirement | DockerRequirement | SoftwareRequirement | InitialWorkDirRequirement | EnvVarRequirement | ShellCommandRequirement | ResourceRequirement | WorkReuse | NetworkAccess | InplaceUpdateRequirement | ToolTimeLimit | SubworkflowFeatureRequirement | ScatterFeatureRequirement | MultipleInputFeatureRequirement | StepInputExpressionRequirement> |
map<class, InlineJavascriptRequirement | SchemaDefRequirement | LoadListingRequirement | DockerRequirement | SoftwareRequirement | InitialWorkDirRequirement | EnvVarRequirement | ShellCommandRequirement | ResourceRequirement | WorkReuse | NetworkAccess | InplaceUpdateRequirement | ToolTimeLimit | SubworkflowFeatureRequirement | ScatterFeatureRequirement | MultipleInputFeatureRequirement | StepInputExpressionRequirement>

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.

cwlVersion
optional
CWLVersion

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

4.3.18.1 ExpressionToolOutputParameter §

Fields

field
required
type
description
type
required
CWLType | OutputRecordSchema | OutputEnumSchema | OutputArraySchema | string | array<CWLType | OutputRecordSchema | OutputEnumSchema | OutputArraySchema | string>

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

label
optional
string

A short, human-readable label of this object.

secondaryFiles
optional
SecondaryFileSchema | array<SecondaryFileSchema>

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

Provides a pattern or expression specifying files or directories that should be included alongside the primary file. Secondary files may be required or optional. When not explicitly specified, secondary files specified for inputs are required and outputs are optional. An implementation must include matching Files and Directories in the secondaryFiles property of the primary file. These Files and Directories must be transferred and staged alongside the primary file. An implementation may fail workflow execution if a required 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. The expression may return "null" in which case there is no secondaryFile from that expression.

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:

  1. If string ends with ? character, remove the last ? and mark the resulting secondary file as optional.
  2. 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.
  3. Append the remainder of the string to the end of the file path.
streamable
optional
boolean

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 object, or an array of strings which should be concatenated.

id
optional
string

The unique identifier for this object.

format
optional
string | Expression

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

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

4.3.18.2 CWLVersion §

Version symbols for published CWL document versions.

Symbols

symboldescription
draft-2
draft-3.dev1
draft-3.dev2
draft-3.dev3
draft-3.dev4
draft-3.dev5
draft-3
draft-4.dev1
draft-4.dev2
draft-4.dev3
v1.0.dev4
v1.0
v1.1.0-dev1
v1.1