saladVersion: v1.1 $base: "https://w3id.org/cwl/cwl#" $namespaces: cwl: "https://w3id.org/cwl/cwl#" sld: "https://w3id.org/cwl/salad#" rdfs: "http://www.w3.org/2000/01/rdf-schema#" $graph: - name: "Common Workflow Language, v1.2.0-dev5" type: documentation doc: {$include: concepts.md} - $import: "salad/schema_salad/metaschema/metaschema_base.yml" - name: BaseTypesDoc type: documentation doc: | ## Base types docChild: - "#CWLType" - "#Process" - type: enum name: CWLVersion doc: "Version symbols for published CWL document versions." symbols: - cwl:draft-2 - cwl:draft-3.dev1 - cwl:draft-3.dev2 - cwl:draft-3.dev3 - cwl:draft-3.dev4 - cwl:draft-3.dev5 - cwl:draft-3 - cwl:draft-4.dev1 - cwl:draft-4.dev2 - cwl:draft-4.dev3 - cwl:v1.0.dev4 - cwl:v1.0 - cwl:v1.1.0-dev1 # a dash is required by the semver 2.0 rules - cwl:v1.1 - cwl:v1.2.0-dev1 - cwl:v1.2.0-dev2 - cwl:v1.2.0-dev3 - cwl:v1.2.0-dev4 - cwl:v1.2.0-dev5 - name: CWLType type: enum extends: "sld:PrimitiveType" symbols: - cwl:File - cwl:Directory doc: - "Extends primitive types with the concept of a file and directory as a builtin type." - "File: A File object" - "Directory: A Directory object" - name: File type: record docParent: "#CWLType" doc: | 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: - name: class type: type: enum name: File_class symbols: - cwl:File jsonldPredicate: _id: "@type" _type: "@vocab" doc: Must be `File` to indicate this object describes a file. - name: location type: string? doc: | 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. jsonldPredicate: _id: "@id" _type: "@id" - name: path type: string? doc: | 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](http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02) (`|`,`&`, `;`, `<`, `>`, `(`,`)`, `$`,`` ` ``, `\`, `"`, `'`, ``, ``, and ``) or characters [not allowed](http://www.iana.org/assignments/idna-tables-6.3.0/idna-tables-6.3.0.xhtml) for [Internationalized Domain Names for Applications](https://tools.ietf.org/html/rfc6452) then implementations may terminate the process with a `permanentFailure`. jsonldPredicate: "_id": "cwl:path" "_type": "@id" - name: basename type: string? doc: | 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`. jsonldPredicate: "cwl:basename" - name: dirname type: string? doc: | 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. - name: nameroot type: string? doc: | 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. - name: nameext type: string? doc: | 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. - name: checksum type: string? doc: | Optional hash code for validating file integrity. Currently must be in the form "sha1$ + hexadecimal string" using the SHA-1 algorithm. - name: size type: long? doc: Optional file size - name: "secondaryFiles" type: - "null" - type: array items: [File, Directory] jsonldPredicate: _id: "cwl:secondaryFiles" secondaryFilesDSL: true doc: | 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. - name: format type: string? jsonldPredicate: _id: cwl:format _type: "@id" identity: true doc: | 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 ` owl:equivalentClass ` and ` owl:subclassOf ` then infer ` owl:subclassOf `. File format ontologies may be provided in the "$schema" metadata at the root of the document. If no ontologies are specified in `$schema`, the runtime may perform exact file format matches. - name: contents type: string? doc: | File contents literal. 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 `contents` is set as a result of an Javascript expression, an `entry` in `InitialWorkDirRequirement`, or read in from `cwl.output.json`, there is no specified upper limit on the size of `contents`. Implementations may have practical limits on the size of `contents` based on memory and storage available to the workflow runner or other factors. If the `loadContents` field of an `InputParameter` or `OutputParameter` is true, and the input or output File object `location` is valid, the file must be a UTF-8 text file 64 KiB or smaller, and the implementation must read the entire contents of the file and place it in the `contents` field. If the size of the file is greater than 64 KiB, the implementation must raise a fatal error. - name: Directory type: record docAfter: "#File" doc: | 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: - name: class type: type: enum name: Directory_class symbols: - cwl:Directory jsonldPredicate: _id: "@type" _type: "@vocab" doc: Must be `Directory` to indicate this object describes a Directory. - name: location type: string? doc: | 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. jsonldPredicate: _id: "@id" _type: "@id" - name: path type: string? doc: | 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](http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02) (`|`,`&`, `;`, `<`, `>`, `(`,`)`, `$`,`` ` ``, `\`, `"`, `'`, ``, ``, and ``) or characters [not allowed](http://www.iana.org/assignments/idna-tables-6.3.0/idna-tables-6.3.0.xhtml) for [Internationalized Domain Names for Applications](https://tools.ietf.org/html/rfc6452) then implementations may terminate the process with a `permanentFailure`. jsonldPredicate: _id: "cwl:path" _type: "@id" - name: basename type: string? doc: | 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`. jsonldPredicate: "cwl:basename" - name: listing type: - "null" - type: array items: [File, Directory] doc: | 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. jsonldPredicate: _id: "cwl:listing" - name: Labeled type: record abstract: true fields: - name: label type: - "null" - string jsonldPredicate: "rdfs:label" doc: "A short, human-readable label of this object." - name: Identified type: record abstract: true fields: - name: id type: string? jsonldPredicate: "@id" doc: "The unique identifier for this object." - name: LoadListingEnum type: enum symbols: [no_listing, shallow_listing, deep_listing] doc: - | Specify the desired behavior for loading the `listing` field of a Directory object for use by expressions. - "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." - name: LoadContents type: record abstract: true fields: - name: loadContents type: boolean? jsonldPredicate: "cwl:loadContents" doc: | Only valid when `type: File` or is an array of `items: File`. If true, the file (or each file in the array) must be a UTF-8 text file 64 KiB or smaller, and the implementation must read the entire contents of the file (or file array) and place it in the `contents` field of the File object for use by expressions. If the size of the file is greater than 64 KiB, the implementation must raise a fatal error. - name: loadListing type: LoadListingEnum? jsonldPredicate: "cwl:loadListing" doc: | 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` - name: FieldBase type: record extends: Labeled abstract: true fields: secondaryFiles: type: - "null" - SecondaryFileSchema - type: array items: SecondaryFileSchema jsonldPredicate: _id: "cwl:secondaryFiles" secondaryFilesDSL: true doc: | 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: type: boolean? doc: | 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`. - name: InputFormat type: record abstract: true fields: format: type: - "null" - string - type: array items: string - Expression jsonldPredicate: _id: cwl:format _type: "@id" identity: true doc: | 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. - name: OutputFormat type: record abstract: true fields: format: type: - "null" - string - Expression jsonldPredicate: _id: cwl:format _type: "@id" identity: true doc: | 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. - name: Parameter type: record extends: [FieldBase, sld:Documented, Identified] abstract: true doc: | Define an input or output parameter to a process. - type: enum name: Expression doc: | 'Expression' is not a real type. It indicates that a field must allow runtime parameter references. If [InlineJavascriptRequirement](#InlineJavascriptRequirement) is declared and supported by the platform, the field must also allow Javascript expressions. symbols: - cwl:ExpressionPlaceholder - name: InputBinding type: record fields: - name: loadContents type: - "null" - boolean jsonldPredicate: "cwl:loadContents" doc: | Use of `loadContents` in `InputBinding` is deprecated. Preserved for v1.0 backwards compatability. Will be removed in CWL v2.0. Use `InputParameter.loadContents` instead. - name: IOSchema extends: [Labeled, sld:Documented] type: record abstract: true fields: - name: name type: string? jsonldPredicate: "@id" doc: "The identifier for this type" - name: InputSchema extends: [IOSchema] type: record abstract: true - name: OutputSchema extends: [IOSchema] type: record abstract: true - name: InputRecordField type: record extends: [sld:RecordField, FieldBase, InputFormat, LoadContents] specialize: - specializeFrom: "sld:RecordSchema" specializeTo: InputRecordSchema - specializeFrom: "sld:EnumSchema" specializeTo: InputEnumSchema - specializeFrom: "sld:ArraySchema" specializeTo: InputArraySchema - specializeFrom: "sld:PrimitiveType" specializeTo: CWLType - name: InputRecordSchema type: record extends: ["sld:RecordSchema", InputSchema] specialize: - specializeFrom: "sld:RecordField" specializeTo: InputRecordField - name: InputEnumSchema type: record extends: ["sld:EnumSchema", InputSchema] - name: InputArraySchema type: record extends: ["sld:ArraySchema", InputSchema] specialize: - specializeFrom: "sld:RecordSchema" specializeTo: InputRecordSchema - specializeFrom: "sld:EnumSchema" specializeTo: InputEnumSchema - specializeFrom: "sld:ArraySchema" specializeTo: InputArraySchema - specializeFrom: "sld:PrimitiveType" specializeTo: CWLType - name: OutputRecordField type: record extends: [sld:RecordField, FieldBase, OutputFormat] specialize: - specializeFrom: "sld:RecordSchema" specializeTo: OutputRecordSchema - specializeFrom: "sld:EnumSchema" specializeTo: OutputEnumSchema - specializeFrom: "sld:ArraySchema" specializeTo: OutputArraySchema - specializeFrom: "sld:PrimitiveType" specializeTo: CWLType - name: OutputRecordSchema type: record extends: ["sld:RecordSchema", "#OutputSchema"] docParent: "#OutputParameter" specialize: - specializeFrom: "sld:RecordField" specializeTo: OutputRecordField - name: OutputEnumSchema type: record extends: ["sld:EnumSchema", OutputSchema] docParent: "#OutputParameter" - name: OutputArraySchema type: record extends: ["sld:ArraySchema", OutputSchema] docParent: "#OutputParameter" specialize: - specializeFrom: "sld:RecordSchema" specializeTo: OutputRecordSchema - specializeFrom: "sld:EnumSchema" specializeTo: OutputEnumSchema - specializeFrom: "sld:ArraySchema" specializeTo: OutputArraySchema - specializeFrom: "sld:PrimitiveType" specializeTo: CWLType - name: InputParameter type: record abstract: true extends: [Parameter, InputFormat, LoadContents] fields: - name: default type: Any? jsonldPredicate: _id: sld:default noLinkCheck: true doc: | 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). - name: OutputParameter type: record extends: [Parameter, OutputFormat] abstract: true - type: record name: ProcessRequirement abstract: true doc: | A process requirement declares a prerequisite that may or must be fulfilled before executing a process. See [`Process.hints`](#process) and [`Process.requirements`](#process). Process requirements are the primary mechanism for specifying extensions to the CWL core specification. - type: record name: Process extends: [Identified, Labeled, sld:Documented] abstract: true doc: | The base executable type in CWL is the `Process` object defined by the document. Note that the `Process` object is abstract and cannot be directly executed. fields: - name: inputs type: type: array items: InputParameter jsonldPredicate: _id: "cwl:inputs" mapSubject: id mapPredicate: type doc: | 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. - name: outputs type: type: array items: OutputParameter jsonldPredicate: _id: "cwl:outputs" mapSubject: id mapPredicate: type doc: | Defines the parameters representing the output of the process. May be used to generate and/or validate the output object. - name: requirements type: ProcessRequirement[]? jsonldPredicate: _id: "cwl:requirements" mapSubject: class doc: | 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. - name: hints type: Any[]? doc: | 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. jsonldPredicate: _id: cwl:hints noLinkCheck: true mapSubject: class - name: cwlVersion type: CWLVersion? doc: | CWL document version. Always required at the document root. Not required for a Process embedded inside another Process. jsonldPredicate: "_id": "cwl:cwlVersion" "_type": "@vocab" - name: intent type: string[]? jsonldPredicate: _type: "@id" identity: true doc: | An identifier for the type of computational operation, of this Process. Especially useful for "class: Operation", but can also be used for CommandLineTool, Workflow, or ExpressionTool. If provided, then this must be an IRI of a concept node that represents the type of operation, preferrably defined within an ontology. For example, in the domain of bioinformatics, one can use an IRI from the EDAM Ontology's [Operation concept nodes](http://edamontology.org/operation_0004), like [Alignment](http://edamontology.org/operation_2928), or [Clustering](http://edamontology.org/operation_3432); or a more specific Operation concept like [Split read mapping](http://edamontology.org/operation_3199). - name: InlineJavascriptRequirement type: record extends: ProcessRequirement doc: | 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: - name: class type: string doc: "Always 'InlineJavascriptRequirement'" jsonldPredicate: "_id": "@type" "_type": "@vocab" - name: expressionLib type: string[]? doc: | Additional code fragments that will also be inserted before executing the expression code. Allows for function definitions that may be called from CWL expressions. - name: CommandInputSchema type: record abstract: true - name: SchemaDefRequirement type: record extends: ProcessRequirement doc: | 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. - **Type definitions are allowed for `enum` and `record` types only.** - Type definitions may be shared by defining them in a file and then `$include`-ing them in the `types` field. - A file can contain a list of type definitions fields: - name: class type: string doc: "Always 'SchemaDefRequirement'" jsonldPredicate: "_id": "@type" "_type": "@vocab" - name: types type: type: array items: CommandInputSchema doc: The list of type definitions. - name: SecondaryFileSchema type: record fields: - name: pattern type: - string - Expression doc: | 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` inputs the `location` field must also be present. For `CommandLineTool` outputs the `path` field must also be present. If secondary files were included on an input File object as part of the Process invocation, they must also be present in `secondaryFiles` on `self`. The expression must return either: a filename string relative to the path to the primary File, a File or Directory object (`class: File` or 'class: Directory`) with either `location` (for inputs) or `path` (for outputs) and `basename` fields set, or an array consisting of strings or File or Directory objects as previously described. It is legal to use `location` from a File or Directory object passed in as input, including `location` from secondary files on `self`. If an expression returns a File object with the same `location` but a different `basename` as a secondary file that was passed in, the expression result takes precedence. Setting the basename with an expression this way affects the `path` where the secondary file will be staged to in the CommandLineTool. The expression may return "null" in which case there is no secondary file from that expression. To work on non-filename-preserving storage systems, portable tool descriptions should treat `location` as an opaque identifier and avoid constructing new values from `location`, but should construct relative references using `basename` or `nameroot` instead, or propagate `location` from defined inputs. 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. - name: required type: ["null", boolean, Expression] doc: | 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. doc: | Secondary files are specified using the following micro-DSL for secondary files: * If the value is a string, it is transformed to an object with two fields `pattern` and `required` * By default, the value of `required` is `null` (this indicates default behavior, which may be based on the context) * If the value ends with a question mark `?` the question mark is stripped off and the value of the field `required` is set to `False` * The remaining value is assigned to the field `pattern` For implementation details and examples, please see [this section](SchemaSalad.html#Domain_Specific_Language_for_secondary_files) in the Schema Salad specification. - name: LoadListingRequirement type: record extends: ProcessRequirement doc: | Specify the desired behavior for loading the `listing` field of a Directory object for use by expressions. fields: class: type: string doc: "Always 'LoadListingRequirement'" jsonldPredicate: "_id": "@type" "_type": "@vocab" loadListing: type: LoadListingEnum? jsonldPredicate: "cwl:loadListing"