Mercurial > repos > shellac > sam_consensus_v3
diff env/lib/python3.9/site-packages/cwltool/schemas/v1.2.0-dev4/Process.yml @ 0:4f3585e2f14b draft default tip
"planemo upload commit 60cee0fc7c0cda8592644e1aad72851dec82c959"
| author | shellac |
|---|---|
| date | Mon, 22 Mar 2021 18:12:50 +0000 |
| parents | |
| children |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/env/lib/python3.9/site-packages/cwltool/schemas/v1.2.0-dev4/Process.yml Mon Mar 22 18:12:50 2021 +0000 @@ -0,0 +1,1029 @@ +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-dev4" + 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 + +- 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) + (`|`,`&`, `;`, `<`, `>`, `(`,`)`, `$`,`` ` ``, `\`, `"`, `'`, + `<space>`, `<tab>`, and `<newline>`) 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 + `<B> owl:equivalentClass <C>` and `<B> owl:subclassOf <A>` then infer + `<C> owl:subclassOf <A>`. + + 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) + (`|`,`&`, `;`, `<`, `>`, `(`,`)`, `$`,`` ` ``, `\`, `"`, `'`, + `<space>`, `<tab>`, and `<newline>`) 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"