comparison env/lib/python3.9/site-packages/cwltool/schemas/v1.2.0-dev4/Process.yml @ 0:4f3585e2f14b draft default tip

"planemo upload commit 60cee0fc7c0cda8592644e1aad72851dec82c959"

0:4f3585e2f14b

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"