galaxy.xsd

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:gxdocs="http://galaxyproject.org/xml/1.0" elementFormDefault="qualified" attributeFormDefault="unqualified">
  <xs:annotation>
    <xs:appinfo>Galaxy Schema</xs:appinfo>
    <xs:documentation xml:lang="en">A Galaxy XML tool wrapper</xs:documentation>
  </xs:annotation>
  <xs:element name="tool">
    <xs:annotation gxdocs:best_practices="tools">
      <xs:documentation xml:lang="en"><![CDATA[
The outer-most tag set of tool XML files. Attributes on this tag apply to the
tool as a whole.

### Tool profile

List of behavior changes associated with profile versions:

#### 16.04

- Disable implicit extra file collection. All dynamic extra file collection requires a `discover_datasets` tag.
- Disable `format="input"` and require explicit metadata targets (`metadata_source`, `format_source`).
- Disable `interpreter` use `$__tool_directory__`.
- Disable `$param_file` use `configfile`.
- Disable default tool version of 1.0.0.
- Use non zero exit code as default stdio error condition (before non-empty stderr).

#### 17.09

- Introduce `provided_metadata_style` with default `"default"`. Restore legacy behavior by setting
  this to `"legacy"`.

#### 18.01

- Use a separate home directory for each job.

#### 18.09

- References to other inputs need to be fully qualified by using `|`.
- Do not allow provided but illegal default values.
- Do not use Galaxy python environment for `manage_data` tools.

#### 19.05

- Change default Python version from 2.7 to 3.5

#### 20.05

- json config files:
   - unselected optional `select` and `data_column` parameters get `None` instead of `"None"`
   - multiple `select` and `data_column` parameters are lists (before comma separated string)

#### 20.09

- Exit immediately if a command exits with a non-zero status (`set -e`).
- Assume sort order for collection elements.

### 21.09

- Do not strip leading and trailing whitespaces in `from_work_dir` attribute.
- Do not use Galaxy Python virtual environment for `data_source` tools. `data_source` tools should explicitly use the `galaxy-util` package.

### 23.0

- Text parameters that are inferred to be optional (i.e the `optional` tag is not set, but the tool parameter accepts an empty string)
  are set to `None` for templating in Cheetah. Older tools receive the empty string `""` as the templated value.

### 24.0

- Do not use Galaxy python environment for `data_source_async` tools.
- Drop request parameters received by data source tools that are not declared in `<request_param_translation>` section.

### 24.2

- require a valid `data_ref` attribute for `data_column` parameters

### Examples

A normal tool:

```xml
<tool id="seqtk_seq"
      name="Convert FASTQ to FASTA"
      version="1.0.0"
      profile="16.04"
>
```

A ``data_source`` tool contains a few more relevant attributes.

```xml
<tool id="ucsc_table_direct1"
      name="UCSC Main"
      version="1.0.0"
      hidden="false"
      profile="16.01"
      tool_type="data_source"
      URL_method="post">
```
      ]]></xs:documentation>
    </xs:annotation>
    <xs:complexType>
      <xs:all>
        <!-- TODO: Move the anyType further into macros def... -->
        <xs:element name="macros" type="Macros" minOccurs="0"/>
        <xs:element name="edam_topics" type="EdamTopics" minOccurs="0"/>
        <xs:element name="edam_operations" type="EdamOperations" minOccurs="0"/>
        <xs:element name="xrefs" type="xrefs" minOccurs="0"/>
        <xs:element name="creator" type="Creator" minOccurs="0"/>
        <xs:element name="requirements" type="Requirements" minOccurs="0"/>
        <xs:element name="required_files" type="RequiredFiles" minOccurs="0"/>
        <xs:element name="entry_points" type="EntryPoints" minOccurs="0" maxOccurs="1"/>
        <xs:element name="description" type="xs:string" minOccurs="0">
          <xs:annotation gxdocs:best_practices="tool-descriptions">
            <xs:documentation xml:lang="en"><![CDATA[The value is displayed in
the tool menu immediately following the hyperlink for the tool (based on the
``name`` attribute of the ``<tool>`` tag set described above).

### Example

```xml
<description>table browser</description>
```
]]></xs:documentation>
          </xs:annotation>
        </xs:element>
        <xs:element name="parallelism" type="Parallelism" minOccurs="0"/>
        <xs:element name="version_command" type="VersionCommand" minOccurs="0"/>
        <xs:element name="action" type="ToolAction" minOccurs="0" maxOccurs="1"/>
        <xs:element name="environment_variables" type="EnvironmentVariables" minOccurs="0" maxOccurs="1"/>
        <xs:element name="command" type="Command" minOccurs="0" maxOccurs="1"/>
        <xs:element name="expression" type="Expression" minOccurs="0" maxOccurs="1"/>
        <xs:element name="request_param_translation" type="RequestParameterTranslation" minOccurs="0"/>
        <xs:element name="configfiles" type="ConfigFiles" minOccurs="0"/>
        <xs:element name="outputs" type="Outputs" minOccurs="0"/>
        <xs:element name="inputs" type="Inputs" minOccurs="0"/>
        <xs:element name="tests" type="Tests" minOccurs="0"/>
        <xs:element name="stdio" type="Stdio" minOccurs="0"/>
        <xs:element name="help" type="Help" minOccurs="0" maxOccurs="1"/>
        <xs:element name="code" type="Code" minOccurs="0"/>
        <xs:element name="uihints" type="UIhints" minOccurs="0"/>
        <xs:element name="options" type="Options" minOccurs="0"/>
        <xs:element name="trackster_conf" type="TracksterConf" minOccurs="0"/>
        <xs:element name="citations" type="Citations" minOccurs="0"/>
      </xs:all>
      <xs:attribute name="id" type="xs:string" use="required">
        <xs:annotation gxdocs:best_practices="tool-ids">
          <xs:documentation xml:lang="en">Must be unique across all tools;
should be lowercase and contain only letters, numbers, and underscores.
It allows for tool versioning and metrics of the number of times a tool is used,
among other things.</xs:documentation>
        </xs:annotation>
      </xs:attribute>
      <xs:attribute name="name" type="xs:string" use="required">
        <xs:annotation gxdocs:best_practices="tool-names">
          <xs:documentation xml:lang="en">This string is what is displayed as a
hyperlink in the tool menu.</xs:documentation>
        </xs:annotation>
      </xs:attribute>
      <xs:attribute name="version" type="xs:string" default="1.0.0">
        <xs:annotation gxdocs:best_practices="tool-versions">
          <xs:documentation xml:lang="en">This string allows for tool versioning
and should be increased with each new version of the tool. The value should
follow the [PEP 440](https://www.python.org/dev/peps/pep-0440/) specification.
It defaults to ``1.0.0`` if it is not included in the tag.</xs:documentation>
        </xs:annotation>
      </xs:attribute>
      <xs:attribute name="hidden" type="PermissiveBoolean" default="false">
        <xs:annotation>
          <xs:documentation xml:lang="en">Allows for tools to be loaded upon
server startup, but not displayed in the tool menu. This attribute should be
applied in the toolbox configuration instead and so should be considered
deprecated.
</xs:documentation>
        </xs:annotation>
      </xs:attribute>
      <xs:attribute name="display_interface" type="PermissiveBoolean">
        <xs:annotation>
          <xs:documentation xml:lang="en">Disable the display the tool's
graphical tool form by setting this to ``false``.</xs:documentation>
        </xs:annotation>
      </xs:attribute>
      <xs:attribute name="tool_type" type="ToolTypeType">
        <xs:annotation>
          <xs:documentation xml:lang="en">Allows for certain framework
functionality to be performed on certain types of tools. Normal tools that execute
typical command-line jobs do not need to specify this, special kinds of tools such
as [Data Source](https://docs.galaxyproject.org/en/latest/dev/data_source.html) and
[Data Manager](https://galaxyproject.org/admin/tools/data-managers/) tools should
set this to have values such as ``data_source``, ``data_source_async`` or
``manage_data``.</xs:documentation>
        </xs:annotation>
      </xs:attribute>
      <xs:attribute name="profile" type="xs:string">
        <xs:annotation gxdocs:best_practices="tool-profile">
          <xs:documentation xml:lang="en">This string specifies the minimum Galaxy
version that should be required to run this tool. Certain legacy behaviors such
as using standard error content to detect errors instead of exit code are disabled
automatically if profile is set to any version newer than ``16.01``. See above
for the list of behavior changes associated with profile versions.
          </xs:documentation>
        </xs:annotation>
      </xs:attribute>
      <xs:attribute name="license" type="xs:string">
        <xs:annotation>
          <xs:documentation xml:lang="en">This string specifies any full URI or a
a short [SPDX](https://spdx.org/licenses/) identifier for a license for this tool
wrapper. The tool wrapper version can be indepedent of the underlying tool. This
license covers the tool XML and associated scripts shipped with the tool.

This is interpreted as [schema.org/license](https://schema.org/license) property.
</xs:documentation>
        </xs:annotation>
      </xs:attribute>
      <xs:attribute name="python_template_version" type="xs:float">
        <xs:annotation>
          <xs:documentation xml:lang="en">This string specifies the minimum Python
version that is able to fill the Cheetah sections of the tool. If unset defaults
to 2.7 if the profile is older than 19.05, otherwise defaults to 3.5. Galaxy will
attempt to convert Python statements in Cheetah sections using [future](http://python-future.org/)
if Galaxy is run on Python 3 and ``python_template_version`` is below 3.</xs:documentation>
        </xs:annotation>
      </xs:attribute>
      <xs:attribute name="workflow_compatible" type="xs:boolean" default="true">
        <xs:annotation>
          <xs:documentation xml:lang="en">This attribute indicates if
this tool is usable within a workflow (defaults to ``true`` for normal tools and
``false`` for data sources).</xs:documentation>
        </xs:annotation>
      </xs:attribute>
      <xs:attribute name="URL_method" type="URLmethodType">
        <xs:annotation>
          <xs:documentation xml:lang="en">*Deprecated* and ignored,
use a [request_param](#tool-request-param-translation-request-param) element with ``galaxy_name="URL_method"`` instead.
Was only used if ``tool_type`` attribute value is ``data_source`` or ``data_source_async`` -
this attribute defined the HTTP request method to use when communicating with an external data source application
(default: ``get``).</xs:documentation>
        </xs:annotation>
      </xs:attribute>
      <xs:attribute name="require_login" type="xs:boolean">
        <xs:annotation>
          <xs:documentation xml:lang="en">Documentation needed</xs:documentation>
        </xs:annotation>
      </xs:attribute>
    </xs:complexType>
  </xs:element>
  <xs:complexType name="Macros">
    <xs:annotation>
      <xs:documentation xml:lang="en">Frequently, tools may require the same XML
fragments be repeated in a file (for instance similar conditional branches,
repeated options, etc...) or among tools in the same repository. Galaxy tools
have a macro system to address this problem.

For more information, see [planemo documentation](https://planemo.readthedocs.io/en/latest/writing_advanced.html#macros-reusable-elements)</xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="import" type="MacroImportType" minOccurs="0" maxOccurs="unbounded">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[
The ``import`` element allows specifying an XML file containing shared macro definitions that can then
be reused by all the tools contained in the same directory/repository.

Example:
````
<macros>
    <import>macros.xml</import>
</macros>
````]]></xs:documentation>
        </xs:annotation>
      </xs:element>
      <xs:element name="token" type="xs:anyType" minOccurs="0" maxOccurs="unbounded">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[
The ``token`` element defines a value, like a constant, that can then be replaced anywhere in any tool importing the token.

Definition example:
````
<macros>
    <token name="@TOOL_VERSION@">1.0.0</token>
</macros>
````

Usage example:
````
<requirements>
    <requirement type="package" version="@TOOL_VERSION@">mypackage</requirement>
</requirements>
````]]></xs:documentation>
        </xs:annotation>
      </xs:element>
      <xs:element name="xml" type="xs:anyType" minOccurs="0" maxOccurs="unbounded">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[
The ``xml`` element, inside macros, allows defining a named XML fragment that can be reused (expanded) anywhere in the tool or tools that use the macro.

Definition example:
````
<macros>
    <xml name="citations">
        <citations>
            ....
        </citations>
    </xml>
</macros>
````

Usage example:
````
<expand macro="citations" />
````
       ]]></xs:documentation>
        </xs:annotation>
      </xs:element>
      <xs:element name="macro" type="xs:anyType" minOccurs="0" maxOccurs="unbounded">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[
A generalisation for macro tokens, templates and xml macros, i.e.
`<macro name="an_xml_macro" type="xml">` is identical to `<xml name="an_xml_macro">`,
`<macro name="a_template" type="template">` is identical to `<template name="a_template">`, and
`<macro name="a_token" type="xml">` is identical to `<token name="a_token">`.
       ]]></xs:documentation>
        </xs:annotation>
      </xs:element>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="EntryPoints">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

This is a container tag set for the ``entry_point`` tag that contains ``port`` and ``url`` tags
described in greater detail below. ``entry_point``s describe InteractiveTool entry points
to a tool.

]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="entry_point" type="EntryPoint" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="EntryPoint" mixed="true">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

This tag set is contained within the ``<entry_point>`` tag set. Access to entry point
ports and urls are included in this tag set. These are used by InteractiveTools
to provide access to graphical tools in real-time.

```xml
<entry_points>
  <entry_point name="Example name" label="example">
    <port>80</port>
    <url>landing/${template_enabled}/index.html</url>
  </entry_point>
</entry_points>
```

]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="port" type="EntryPointPort" minOccurs="1" maxOccurs="1"/>
      <xs:element name="url" type="EntryPointURL" minOccurs="0" maxOccurs="1"/>
    </xs:sequence>
    <xs:attribute name="name" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en">The name of the entry point.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="label" type="xs:string" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en">A unique label to identify the entry point. Used by interactive client tools to connect.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="requires_domain" type="PermissiveBoolean" default="true">
      <xs:annotation>
        <xs:documentation xml:lang="en">Whether domain-based proxying is required for the entry point. Default is True.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="requires_path_in_url" type="PermissiveBoolean" default="false">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
Whether the InteractiveTool proxy will add the entry point path to the URL provided to the interactive tool. Only
relevant when path-based proxying is configured (``requires_domain=False``). A value of False implies that the web service
for the interactive tool fully operates with relative links. A value of True implies that the unique entry point path,
which is autogenerated each run, must be somehow provided to the web service. This can be done by injecting the path
into an environment variable by setting the attribute ``inject="entry_point_path_for_label"`` in the tool XML.
Alternatively, the attribute ``requires_path_in_header_named`` can be set to provide the path in the specified HTTP header.
The entry point path should in any case be used to configure the web service in the interactive tool to serve the content
from the provided URL path. Default value of ``requires_path_in_url`` is False.
]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="requires_path_in_header_named" type="xs:string" default="">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
Whether the InteractiveTool proxy will add the entry point path to an HTTP header. An empty string as value (default) means
that the path will not be provided in an HTTP header. Any other string value will define the name of the HTTP header
where the path will be injected by the proxy. See the documentation of ``requires_path_in_url`` for more information.
Default value of ``requires_path_in_header_named`` is False.
]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="EntryPointPort" mixed="true">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

This tag set is contained within the ``<entry_point>`` tag set. It contains the entry port.

]]></xs:documentation>
    </xs:annotation>
  </xs:complexType>
  <xs:complexType name="EntryPointURL" mixed="true">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

This tag set is contained within the ``<entry_point>`` tag set. It contains the entry URL.

]]></xs:documentation>
    </xs:annotation>
  </xs:complexType>
  <xs:complexType name="ToolAction">
    <xs:annotation>
      <xs:documentation xml:lang="en">Describe the backend Python action to execute for this Galaxy tool.</xs:documentation>
    </xs:annotation>
    <xs:sequence>
    </xs:sequence>
    <xs:attribute name="module" type="xs:string" use="required">
    </xs:attribute>
    <xs:attribute name="class" type="xs:string" use="required">
    </xs:attribute>
  </xs:complexType>
  <xs:attributeGroup name="Thing">
    <xs:attribute name="name" type="xs:string" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en">[schema.org/name](https://schema.org/name)</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="url" type="xs:string" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en">[schema.org/url](https://schema.org/url)</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="identifier" type="xs:string" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en">[schema.org/identifier](https://schema.org/identifier)</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="image" type="xs:string" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en">[schema.org/image](https://schema.org/image)</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="address" type="xs:string" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en">[schema.org/address](https://schema.org/address)</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="email" type="xs:string" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en">[schema.org/email](https://schema.org/email)</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="telephone" type="xs:string" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en">[schema.org/telephone](https://schema.org/telephone)</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="faxNumber" type="xs:string" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en">[schema.org/faxNumber](https://schema.org/faxNumber)</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="alternateName" type="xs:string" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en">[schema.org/alternateName](https://schema.org/alternateName)</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:attributeGroup>
  <xs:complexType name="Person">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[
Describes a person. Tries to stay close to [schema.org/Person](https://schema.org/Person).
]]></xs:documentation>
    </xs:annotation>
    <xs:attributeGroup ref="Thing"/>
    <xs:attribute name="givenName" type="xs:string" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en">[schema.org/givenName](https://schema.org/givenName)</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="familyName" type="xs:string" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en">[schema.org/familyName](https://schema.org/familyName)</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="honorificPrefix" type="xs:string" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en">[schema.org/honorificPrefix](https://schema.org/honorificPrefix)</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="honorificSuffix" type="xs:string" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en">[schema.org/honorificSuffix](https://schema.org/honorificSuffix)</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="jobTitle" type="xs:string" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en">[schema.org/jobTitle](https://schema.org/jobTitle)</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="Organization">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[
Describes an organization. Tries to stay close to [schema.org/Organization](https://schema.org/Organization).
]]></xs:documentation>
    </xs:annotation>
    <xs:attributeGroup ref="Thing"/>
  </xs:complexType>
  <xs:group name="PersonOrOrganization">
    <xs:choice>
      <xs:element name="person" type="Person"/>
      <xs:element name="organization" type="Organization"/>
    </xs:choice>
  </xs:group>
  <xs:complexType name="Creator">
    <xs:annotation>
      <xs:documentation xml:lang="en">The creator(s) of this work. See [schema.org/creator](https://schema.org/creator).</xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:group ref="PersonOrOrganization" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="RequiredFiles">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[
This declaration is used to define files that must be shipped from the tool directory
for the tool to function properly in remote environments where the tool directory
is not available to the job.

All includes should be list before excludes. By default, the exclude list includes
the tool-data/**, test-data/**, and .hg/** glob patterns.

Pulsar hacks to implicitly find referenced files from the tool directory will be disabled
when this block is used. A future Galaxy tool profile version may disable these hacks
altogether and specifying this block for all referenced files should be considered a best
practice.
]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="include" type="RequiredFileInclude" minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="exclude" type="RequiredFileExclude" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="extend_default_excludes" type="xs:boolean" default="true">
      <xs:annotation>
        <xs:documentation xml:lang="en">Set this to `false` to override the default excludes for mercurial, reference, and test data.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:simpleType name="RequiredFileReferenceType">
    <xs:annotation>
      <xs:documentation xml:lang="en">How are files referenced in RequiredFileIncludes and RequiredFileExcludes. Paths are matched relative to the tool directory. `literal` must match the filename exactly. `prefix` will match paths based on their start. `glob` and `regex` use patterns to match files.</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="literal"/>
      <xs:enumeration value="prefix"/>
      <xs:enumeration value="glob"/>
      <xs:enumeration value="regex"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:complexType name="RequiredFileInclude">
    <xs:annotation>
      <xs:documentation xml:lang="en">Describe files to include when relocating tool directory for remote execution.</xs:documentation>
    </xs:annotation>
    <xs:attribute name="type" type="RequiredFileReferenceType">
      <xs:annotation>
        <xs:documentation xml:lang="en">Type of file reference `path` is.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="path" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Path to referenced files - this should be relative to the tool's directory (this is the file the tool is located in not the repository directory if these conflict).</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="RequiredFileExclude">
    <xs:annotation>
      <xs:documentation xml:lang="en">Describe files to exclude when relocating tool directory for remote execution.</xs:documentation>
    </xs:annotation>
    <xs:attribute name="type" type="RequiredFileReferenceType">
      <xs:annotation>
        <xs:documentation xml:lang="en">Type of file reference `path` is.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="path" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Path to referenced files - this should be relative to the tool's directory (this is the file the tool is located in not the repository directory if these conflict).</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="Requirements">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

This is a container tag set for the ``requirement``, ``resource`` and ``container`` tags
described in greater detail below. ``requirement``s describe software packages
and other individual computing requirements required to execute a tool, while
``container``s describe Docker or Singularity containers that should be able to
serve as complete descriptions of the runtime of a tool.

]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="requirement" type="Requirement" minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="container" type="Container" minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="resource" type="Resource" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="Requirement">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

This tag set is contained within the ``<requirements>`` tag set. Third party
programs or modules that the tool depends upon are included in this tag set.

When a tool runs, Galaxy attempts to *resolve* these requirements (also called
dependencies). ``requirement``s are meant to be abstract and resolvable by
multiple different [dependency resolvers](../admin/dependency_resolvers) (e.g. [conda](https://conda.io/), the
[Galaxy Tool Shed dependency management system](https://galaxyproject.org/toolshed/tool-features/),
or [environment modules](https://modules.sourceforge.net/)).

The current best practice for tool dependencies is to [target Conda](../admin/conda_faq).

### Examples

This example shows a tool that requires the samtools 0.0.18 package.

This package is available via the Tool Shed (see
[Tool Shed dependency management](https://galaxyproject.org/toolshed/tool-features/)
) as well as [Conda](../admin/conda_faq)
and can be configured locally to adapt to any other package management system.

```xml
<requirements>
    <requirement type="package" version="0.1.18">samtools</requirement>
</requirements>
```

This older example shows a tool that requires R version 2.15.1. The
``tool_dependencies.xml`` should contain matching declarations for Galaxy to
actually install the R runtime. The ``set_envirornment`` type is only respected
by the tool shed and is ignored by the newer and preferred conda dependency
resolver.

```xml
<requirements>
    <requirement type="set_environment">R_SCRIPT_PATH</requirement>
    <requirement type="package" version="2.15.1">R</requirement>
</requirements>
```

]]></xs:documentation>
    </xs:annotation>
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="type" type="RequirementType" use="required">
          <xs:annotation>
            <xs:documentation xml:lang="en">Valid values are ``package``, ``set_environment``, ``python-module`` (deprecated), ``binary`` (deprecated)</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="version" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en">For requirements of type ``package`` this value defines a specific version of the tool dependency.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="Resource">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[
Allows to describe a resource requirement of a tool. At the moment this tag is mostly descriptive,
It can be used by dynamic job rules and serves to guide Galaxy admins.
]]></xs:documentation>
    </xs:annotation>
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="type" type="ResourceType" use="required">
          <xs:annotation>
            <xs:documentation xml:lang="en">This value describes the type of resource required by the tool at runtime. Not yet implemented in Galaxy.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="Container">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[
This tag set is contained within the 'requirements' tag set. Galaxy can be
configured to run tools within [Docker](https://www.docker.com/) or [Singularity](https://www.sylabs.io/singularity/)
containers - this tag allows the tool to suggest possible valid containers for this tool. The contents of the tag should
be a container image identifier appropriate for the particular container runtime being used, e.g.
``quay.io/biocontainers/fastqc:0.11.2--1`` for Docker or ``docker://quay.io/biocontainers/fastqc:0.11.2--1``
(or alternatively ``/opt/containers/fastqc.simg`` if your Galaxy installation will be loading the image from a filesystem path)
for Singularity. The ``requirements`` tag can contain multiple ``container`` tags describing suitable container options, in
which case the first container that is found by the Galaxy container resolver at runtime will be used.

Example:

```xml
<requirements>
  <container type="docker">quay.io/biocontainers/fastqc:0.11.2--1</container>
</requirements>
```

Read more about configuring Galaxy to run Docker jobs
[here](https://docs.galaxyproject.org/en/master/admin/container_resolvers.html).
]]></xs:documentation>
    </xs:annotation>
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="type" type="ContainerType" use="required">
          <xs:annotation>
            <xs:documentation xml:lang="en">This value describes the type of container that the tool may be executed in and currently may be ``docker`` or ``singularity``.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:simpleType name="HelpFormatType">
    <xs:annotation>
      <xs:documentation xml:lang="en">Document type of tool help</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="restructuredtext"/>
      <xs:enumeration value="markdown"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:complexType name="Help">
    <xs:annotation gxdocs:best_practices="help-tag">
      <xs:documentation xml:lang="en"><![CDATA[This tag set includes all of the necessary details of how to use the tool. This tag set should be included as the next to the last tag set, before citations, in the tool config. Tool help is written in reStructuredText. Included here is only an overview of a subset of features. For more information see [here](https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html).

tag | details
--- | -------
``.. class:: warningmark`` | a yellow warning symbol
``.. class:: infomark`` | a blue information symbol
``.. image:: path-of-the-file.png :height: 500 :width: 600`` | insert a png file of height 500 and width 600 at this position |
``**bold**`` | bold
``*italic*`` | italic
``*`` | list
``-`` | list
``::`` | paragraph
``-----`` | a horizontal line

### Examples

Show a warning sign to remind users that this tool accept fasta format files only, followed by an example of the query sequence and a figure.

```xml
<help>

.. class:: warningmark

'''TIP''' This tool requires *fasta* format.

----

'''Example'''

Query sequence::
    >seq1
    ATCG...

.. image:: my_figure.png
    :height: 500
    :width: 600

</help>
```

]]></xs:documentation>
    </xs:annotation>
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="format" type="HelpFormatType">
          <xs:annotation>
            <xs:documentation xml:lang="en">Valid values are ``restructuredtext`` and ``markdown``</xs:documentation>
          </xs:annotation>
        </xs:attribute>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="Parallelism">
    <xs:annotation>
      <xs:documentation xml:lang="en">Documentation for Parallelism</xs:documentation>
    </xs:annotation>
    <xs:attribute name="method" type="MethodType">
      <xs:annotation>
        <xs:documentation xml:lang="en">Documentation for method</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="merge_outputs" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Documentation for merge_outputs</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="split_inputs" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">A comma-separated list of data inputs to split for job parallelization.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="split_size" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Documentation for split_size</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="split_mode" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Documentation for split_mode</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="shared_inputs" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">A comma-separated list of data inputs that should not be split for this tool, Galaxy will infer this if not present and so this potentially never needs to be set.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="Code">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[
*Deprecated*. Do not use this unless absolutely necessary.

The extensions described here can cause problems using your tool with certain components
of Galaxy (like the workflow system). It is highly recommended to avoid these constructs
unless absolutely necessary.

This tag set provides detailed control of the way the tool is executed. This
(optional) code can be deployed in a separate file in the same directory as the
tool's config file. These hooks are being replaced by new tool config features
and methods in the [/lib/galaxy/tools/\__init__.py](https://github.com/galaxyproject/galaxy/blob/dev/lib/galaxy/tools/__init__.py) code file.

### Examples

#### Dynamic Options

Use associated dynamic select lists where selecting an option in the first
select list dynamically re-renders the options in the second select list. In
this example, we are populating both dynamic select lists from metadata elements
associated with a tool's single input dataset. The 2 metadata elements we're
using look like this.

```python
MetadataElement(name="field_names", default=[], desc="Field names", readonly=True, optional=True, visible=True, no_value=[])
# The keys in the field_components map to the list of field_names in the above element
# which ensures order for select list options that are built from it.
MetadataElement(name="field_components", default={}, desc="Field names and components", readonly=True, optional=True, visible=True, no_value={})
```

Our tool config includes a code file tag like this.

```xml
<code file="tool_form_utils.py" />
```

Here are the relevant input parameters in our tool config. The first parameter
is the input dataset that includes the above metadata elements.

```xml
<param name="input" type="data" format="vtkascii,vtkbinary" label="Shape with uncolored surface field">
    <validator type="expression" message="Shape must have an uncolored surface field.">value is not None and len(value.metadata.field_names) > 0</validator>
</param>
```

The following parameter dynamically renders a select list consisting of the
elements in the ``field_names`` metadata element associated with the selected
input dataset.

```xml
<param name="field_name" type="select" label="Field name" refresh_on_change="true">
    <options>
        <filter type="data_meta" ref="input" key="field_names"/>
    </options>
    <validator type="no_options" message="The selected shape has no uncolored surface fields." />
</param>
```

The following parameter calls the ``get_field_components_options()`` function in
the ``tool_form_utils.py`` code file discussed above. This function returns the
value of the input dataset's ``field_components`` metadata element dictionary
whose key is the currently selected ``field_name`` from the select list parameter
above.

```xml
<param name="field_component_index" type="select" label="Field component index" dynamic_options="get_field_components_options(input, field_name=field_name)" help="Color will be applied to the selected field's component associated with this index." />
```

Changing the selected option in the ``field_name`` select list will dynamically
re-render the options available in the associated ``field_component_index`` select
list, which is the behavior we want.

The ``get_field_components_options()`` method looks like this.

```python
def get_field_components_options(dataset, field_name):
    options = []
    if dataset.metadata is None:
        return options
    if not hasattr(dataset.metadata, 'field_names'):
        return options
    if dataset.metadata.field_names is None:
        return options
    if field_name is None:
        # The expression validator that helps populate the select list of input
        # datsets in the icqsol_color_surface_field tool does not filter out
        # datasets with no field field_names, so we need this check.
        if len(dataset.metadata.field_names) == 0:
            return options
        field_name = dataset.metadata.field_names[0]
    field_components = dataset.metadata.field_components.get(field_name, [])
    for i, field_component in enumerate(field_components):
        options.append((field_component, field_component, i == 0))
    return options
```

#### Parameter Validation

This function is called before the tool is executed. If it raises any exceptions the tool execution will be aborted and the exception's value will be displayed in an error message box. Here is an example:

```python
def validate(incoming):
    """Validator for the plotting program"""


    bins = incoming.get("bins","")
    col = incoming.get("col","")


    if not bins or not col:
        raise Exception, "You need to specify a number for bins and columns"


    try:
        bins = int(bins)
        col = int(col)
    except:
        raise Exception, "Parameters are not integers, columns:%s, bins:%s" % (col, bins)


    if not 1<bins<100:
        raise Exception, "The number of bins %s must be a number between 1 and 100" % bins
```

This code will intercept a number of parameter errors and return corresponding error messages. The parameter ``incoming`` contains a dictionary with all the parameters that were sent through the web.

#### Pre-job and pre-process code

The signature of both of these is the same:

```python
def exec_before_job(inp_data, out_data, param_dict, tool):
def exec_before_process(inp_data, out_data, param_dict, tool):
```

The ``param_dict`` is a dictionary that contains all the values in the ``incoming`` parameter above plus a number of keys and values generated internally by galaxy. The ``inp_data`` and the ``out_data`` are dictionaries keyed by parameter name containing the classes that represent the data.

Example:

```python
def exec_before_process(inp_data, out_data, param_dict, tool):
    for name, data in out_data.items():
        data.name = 'New name'
```

This custom code will change the name of the data that was created for this tool to **New name**. The difference between these two functions is that the ``exec_before_job`` executes before the page returns and the user will see the new name right away. If one were to use ``exec_before_process`` the new name would be set only once the job starts to execute.

#### Post-process code

This code executes after the background process running the tool finishes its run. The example below is more advanced one that replaces the type of the output data depending on the parameter named ``extension``:

```python
from galaxy import datatypes
def exec_after_process(app, inp_data, out_data, param_dict, tool, stdout, stderr):
    ext = param_dict.get('extension', 'text')
    items = out_data.items()
    for name, data in items:
        newdata = datatypes.factory(ext)(id=data.id)
        for key, value in data. __dict__.items():
            setattr(newdata, key, value)
        newdata.ext = ext
        out_data[name] = newdata
```

The content of ``stdout`` and ``stderr`` are strings containing the output of the process.

]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="hook" type="CodeHook" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="file" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en">This value is the name of the executable code file, and is called in the ``exec_before_process()``, ``exec_before_job()``, ``exec_after_process()`` and ``exec_after_job()`` methods.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="CodeHook">
    <xs:annotation>
      <xs:documentation xml:lang="en">*Deprecated*. Map a hook to a function defined in the code file.</xs:documentation>
    </xs:annotation>
    <xs:attribute name="exec_after_process" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Function defined in the code file to which the ``exec_after_process`` hook should be mapped</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="UIhints">
    <xs:annotation>
      <xs:documentation xml:lang="en">Used only for data source tools, this directive contains UI options (currently only ``minwidth`` is valid).</xs:documentation>
    </xs:annotation>
    <xs:attribute name="minwidth" type="xs:integer">
      <xs:annotation>
        <xs:documentation xml:lang="en">Documentation for minwidth</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="Options">
    <xs:annotation>
      <xs:documentation xml:lang="en">This directive is used to specify some rarely modified options.</xs:documentation>
    </xs:annotation>
    <xs:attribute name="refresh" type="PermissiveBoolean" gxdocs:deprecated="true">
      <xs:annotation>
        <xs:documentation xml:lang="en">*Deprecated*. Unused attribute.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="sanitize" type="PermissiveBoolean" default="true">
      <xs:annotation>
        <xs:documentation xml:lang="en">This attribute can be used to turn off all input sanitization for a tool.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="TracksterConf">
    <xs:annotation>
      <xs:documentation xml:lang="en">This directive is used to specify some rarely modified trackster options.</xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="action" type="TracksterAction" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="TracksterAction">
    <xs:annotation>
      <xs:documentation xml:lang="en"/>
    </xs:annotation>
    <xs:attribute name="name" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en"/>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="output_name" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en"/>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="Tests">
    <xs:annotation gxdocs:best_practices="tests">
      <xs:documentation xml:lang="en"><![CDATA[

Container tag set to specify tests via the ``<test>`` tag sets. Any number of tests can be included,
and each test is wrapped within separate ``<test>`` tag sets. Functional tests are
executed via [Planemo](https://planemo.readthedocs.io/) or the
[run_tests.sh](https://github.com/galaxyproject/galaxy/blob/dev/run_tests.sh)
shell script distributed with Galaxy.

The documentation contained here is mostly reference documentation, for
tutorials on writing tool tests please check out Planemo's
[Test-Driven Development](https://planemo.readthedocs.io/en/latest/writing_advanced.html#test-driven-development)
documentation or the much older wiki content for
[WritingTests](https://galaxyproject.org/admin/tools/writing-tests/).

]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="test" type="Test" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="Test">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

This tag set contains the necessary parameter values for executing the tool via
the functional test framework.

### Example

The following two tests will execute the
[/tools/filters/sorter.xml](https://github.com/galaxyproject/galaxy/blob/dev/tools/filters/sorter.xml)
tool. Notice the way that the tool's inputs and outputs are defined.

```xml
  <tests>
    <test>
      <param name="input" value="1.bed" ftype="bed" />
      <param name="column" value="1"/>
      <param name="order" value="ASC"/>
      <param name="style" value="num"/>
      <output name="out_file1" file="sort1_num.bed" ftype="bed" />
    </test>
    <test>
      <param name="input" value="7.bed" ftype="bed" />
      <param name="column" value="1"/>
      <param name="order" value="ASC"/>
      <param name="style" value="alpha"/>
      <output name="out_file1" file="sort1_alpha.bed" ftype="bed" />
    </test>
  </tests>
```

The following example, tests the execution of the MAF-to-FASTA converter
([/tools/maf/maf_to_fasta.xml](https://github.com/galaxyproject/galaxy/blob/dev/tools/maf/maf_to_fasta.xml)).

```xml
<tests>
    <test>
        <param name="input1" value="3.maf" ftype="maf"/>
        <param name="species" value="canFam1"/>
        <param name="fasta_type" value="concatenated"/>
        <output name="out_file1" file="cf_maf2fasta_concat.dat" ftype="fasta"/>
    </test>
</tests>
```

This test demonstrates verifying specific properties about a test output instead
of directly comparing it to another file. Here the file attribute is not
specified and instead a series of assertions is made about the output.

```xml
<test>
    <param name="input" value="maf_stats_interval_in.dat" />
    <param name="lineNum" value="99999"/>
    <output name="out_file1">
        <assert_contents>
            <has_text text="chr7" />
            <not_has_text text="chr8" />
            <has_text_matching expression="1274\d+53" />
            <has_line_matching expression=".*\s+127489808\s+127494553" />
            <!-- &#009; is XML escape code for tab -->
            <has_line line="chr7&#009;127471195&#009;127489808" />
            <has_n_columns n="3" />
            <has_n_lines n="3" />
        </assert_contents>
    </output>
</test>
```

]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:group ref="TestParamElement" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="expect_exit_code" type="xs:integer">
      <xs:annotation>
        <xs:documentation xml:lang="en">Describe the job's expected exit code.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="expect_num_outputs" type="xs:integer">
      <xs:annotation>
        <xs:documentation xml:lang="en">Assert the number of statically defined items (datasets and collections) this test
should produce. Each `data` or `collection` tag that is listed in the
outputs section is a statically defined output and adds one to this count.  For
instance a statically defined pair adds a count of 3; 1 for the collection and 1 for each
of the two datasets.  Dynamically defined output datasets (using ``discover_datasets`` tag)
are not counted here, but note that the ``collection`` or ``data`` tag that
includes the ``discover_datasets`` still adds a count of one.  This is useful to
ensure ``filter`` directives are implemented correctly.  See
[here](https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/expect_num_outputs.xml)
for examples.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="expect_failure" type="PermissiveBoolean" default="false">
      <xs:annotation>
        <xs:documentation xml:lang="en">Setting this to ``true`` indicates
the expectation is for the job fail. If set to ``true`` no job output checks may
be present in ``test`` definition.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="expect_test_failure" type="PermissiveBoolean" default="false">
      <xs:annotation>
        <xs:documentation xml:lang="en">Setting this to ``true`` indicates
that at least one of the assumptions of the test is not met. This is most useful for internal testing.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="maxseconds" type="xs:integer">
      <xs:annotation>
        <xs:documentation xml:lang="en">Maximum amount of time to let test run.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:group name="TestParamElement">
    <xs:choice>
      <xs:element name="param" type="TestParam"/>
      <xs:element name="repeat" type="TestRepeat"/>
      <xs:element name="conditional" type="TestConditional"/>
      <xs:element name="section" type="TestSection"/>
      <xs:element name="output" type="TestOutput" minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="output_collection" type="TestOutputCollection"/>
      <xs:element name="assert_command" type="TestAssertions">
        <xs:annotation>
          <xs:documentation xml:lang="en">Describe assertions about the job's
generated command-line.

$assertions
</xs:documentation>
        </xs:annotation>
      </xs:element>
      <xs:element name="assert_stdout" type="TestAssertions">
        <xs:annotation>
          <xs:documentation xml:lang="en">Describe assertions about the job's
standard output.

$assertions
</xs:documentation>
        </xs:annotation>
      </xs:element>
      <xs:element name="assert_stderr" type="TestAssertions">
        <xs:annotation>
          <xs:documentation xml:lang="en">Describe assertions about the job's
standard error.

$assertions
</xs:documentation>
        </xs:annotation>
      </xs:element>
      <xs:element name="assert_command_version" type="TestAssertions">
        <xs:annotation>
          <xs:documentation xml:lang="en">Describe assertions about the job's
command version.

$assertions
</xs:documentation>
        </xs:annotation>
      </xs:element>
    </xs:choice>
  </xs:group>
  <xs:complexType name="TestSection">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

Specify test parameters below a named of a ``section`` block matching
one in ``inputs`` with this element.

``param`` elements in a ``test`` block can be arranged into nested ``repeat``,
``conditional``, and ``select`` structures to match the inputs. While this might
be overkill for simple tests, it helps prevent ambiguous definitions and keeps
things organized in large test cases. A future ``profile`` version of Galaxy
tools may require ``section`` blocks be explicitly defined with this
directive.

### Examples

The test tool demonstrating sections
([section.xml](https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/section.xml))
contains a test case demonstrating this block. This test case appears below:

```xml
<test>
    <section name="int">
        <param name="inttest" value="12456" />
    </section>
    <section name="float">
        <param name="floattest" value="6.789" />
    </section>
    <output name="out_file1">
        <assert_contents>
            <has_line line="12456" />
            <has_line line="6.789" />
        </assert_contents>
    </output>
</test>
```

]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:group ref="TestParamElement" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="name" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en">This value must match the name of the
associated input ``section``.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="TestConditional">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

Specify test parameters below a named of a ``conditional`` block matching
one in ``inputs`` with this element.

``param`` elements in a ``test`` block can be arranged into nested ``repeat``,
``conditional``, and ``select`` structures to match the inputs. While this might
be overkill for simple tests, it helps prevent ambiguous definitions and keeps
things organized in large test cases. A future ``profile`` version of Galaxy
tools may require ``conditional`` blocks be explicitly defined with this
directive.

### Examples

The following example demonstrates disambiguation of a parameter (named ``use``)
which appears in multiple ``param`` names in ``conditional``s in the ``inputs``
definition of the [disambiguate_cond.xml](https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/disambiguate_cond.xml)
tool.

```xml
<!-- Can use nested conditional blocks as shown below to disambiguate
     various nested parameters. -->
<test>
    <conditional name="p1">
        <param name="use" value="False"/>
    </conditional>
    <conditional name="p2">
        <param name="use" value="True"/>
    </conditional>
    <conditional name="p3">
        <param name="use" value="False"/>
    </conditional>
    <conditional name="files">
        <param name="attach_files" value="True" />
        <conditional name="p4">
            <param name="use" value="True"/>
            <param name="file" value="simple_line_alternative.txt" />
        </conditional>
    </conditional>
    <output name="out_file1">
        <assert_contents>
            <has_line line="7 4 7" />
            <has_line line="This is a different line of text." />
        </assert_contents>
    </output>
</test>
```

The [tophat2](https://github.com/galaxyproject/tools-devteam/blob/main/tools/tophat2/tophat2_wrapper.xml)
tool demonstrates a real tool that benefits from more structured test cases
using the ``conditional`` test directive. One such test case from that tool is
shown below.

```xml
<!-- Test base-space paired-end reads with user-supplied reference fasta and full parameters -->
<test>
    <!-- TopHat commands:
    tophat2 -o tmp_dir -r 20 -p 1 -a 8 -m 0 -i 70 -I 500000 -g 40 +coverage-search +min-coverage-intron 50 +max-coverage-intro 20000 +segment-mismatches 2 +segment-length 25 +microexon-search +report_discordant_pairs tophat_in1 test-data/tophat_in2.fastqsanger test-data/tophat_in3.fastqsanger
    Replace the + with double-dash
    Rename the files in tmp_dir appropriately
    -->
    <conditional name="singlePaired">
      <param name="sPaired" value="paired"/>
      <param name="input1" ftype="fastqsanger" value="tophat_in2.fastqsanger"/>
      <param name="input2" ftype="fastqsanger" value="tophat_in3.fastqsanger"/>
      <param name="mate_inner_distance" value="20"/>
      <param name="report_discordant_pairs" value="Yes" />
    </conditional>
    <param name="genomeSource" value="indexed"/>
    <param name="index" value="tophat_test"/>
    <conditional name="params">
      <param name="settingsType" value="full"/>
      <param name="library_type" value="FR Unstranded"/>
      <param name="read_mismatches" value="5"/>
      <!-- Error: the read mismatches (5) and the read gap length (2) should be less than or equal to the read edit dist (2) -->
      <param name="read_edit_dist" value="5" />
      <param name="bowtie_n" value="Yes"/>
      <param name="mate_std_dev" value="20"/>
      <param name="anchor_length" value="8"/>
      <param name="splice_mismatches" value="0"/>
      <param name="min_intron_length" value="70"/>
      <param name="max_intron_length" value="500000"/>
      <param name="max_multihits" value="40"/>
      <param name="min_segment_intron" value="50" />
      <param name="max_segment_intron" value="500000" />
      <param name="seg_mismatches" value="2"/>
      <param name="seg_length" value="25"/>
      <conditional name="indel_search">
        <param name="allow_indel_search" value="No"/>
      </conditional>
      <conditional name="own_junctions">
        <param name="use_junctions" value="Yes" />
        <conditional name="gene_model_ann">
          <param name="use_annotations" value="No" />
        </conditional>
        <conditional name="raw_juncs">
          <param name="use_juncs" value="No" />
        </conditional>
        <conditional name="no_novel_juncs">
          <param name="no_novel_juncs" value="No" />
        </conditional>
      </conditional>
      <conditional name="coverage_search">
        <param name="use_search" value="No" />
      </conditional>
      <param name="microexon_search" value="Yes" />
      <conditional name="bowtie2_settings">
        <param name="b2_settings" value="No" />
      </conditional>
      <!-- Fusion search params -->
      <conditional name="fusion_search">
        <param name="do_search" value="Yes" />
        <param name="anchor_len" value="21" />
        <param name="min_dist" value="10000021" />
        <param name="read_mismatches" value="3" />
        <param name="multireads" value="4" />
        <param name="multipairs" value="5" />
        <param name="ignore_chromosomes" value="chrM"/>
      </conditional>
    </conditional>
    <conditional name="readGroup">
      <param name="specReadGroup" value="no" />
    </conditional>
    <output name="junctions" file="tophat2_out4j.bed" />
    <output name="accepted_hits" file="tophat_out4h.bam" compare="sim_size" />
</test>
```

]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:group ref="TestParamElement" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="name" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en">This value must match the name of the
associated input ``conditional``.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="TestRepeat">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

Specify test parameters below an iteration of a ``repeat`` block with this
element.

``param`` elements in a ``test`` block can be arranged into nested ``repeat``,
``conditional``, and ``select`` structures to match the inputs. While this might
be overkill for simple tests, it helps prevent ambiguous definitions and keeps
things organized in large test cases. A future ``profile`` version of Galaxy
tools may require ``repeat`` blocks be explicitly defined with this directive.

### Examples

The test tool [disambiguate_repeats.xml](https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/disambiguate_repeats.xml)
demonstrates the use of this directive.

This first test case demonstrates that this block allows different values for
the ``param`` named ``input`` to be tested even though this parameter name
appears in two different ``<repeat>`` elements in the ``<inputs>`` definition.

```xml
<!-- Can disambiguate repeats and specify multiple blocks using,
     nested structure. -->
<test>
    <repeat name="queries">
        <param name="input" value="simple_line.txt"/>
    </repeat>
    <repeat name="more_queries">
        <param name="input" value="simple_line_alternative.txt"/>
    </repeat>
    <output name="out_file1">
        <assert_contents>
            <has_line line="This is a line of text." />
            <has_line line="This is a different line of text." />
        </assert_contents>
    </output>
</test>
```

The second definition in that file demonstrates repeated ``<repeat>`` blocks
allowing multiple instances of a single repeat to be specified.

```xml
<!-- Multiple such blocks can be specified but only with newer API
     driven tests. -->
<test>
    <repeat name="queries">
        <param name="input" value="simple_line.txt"/>
    </repeat>
    <repeat name="queries">
        <param name="input" value="simple_line_alternative.txt"/>
    </repeat>
    <repeat name="more_queries">
        <param name="input" value="simple_line.txt"/>
    </repeat>
    <repeat name="more_queries">
        <param name="input" value="simple_line_alternative.txt"/>
    </repeat>
    <output name="out_file1" file="simple_lines_interleaved.txt"/>
</test>
```

]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:group ref="TestParamElement" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="name" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en">This value must match the name of the
associated input ``repeat``.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="TestParam">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

This tag set defines the tool's input parameters for executing the tool via the
functional test framework. See [test](#tool-tests-test) documentation for
some simple examples of parameters.

### Parameter Types

#### ``text``, ``integer``, and ``float``

Values for these parameters are simply given by the desired value.

#### ``boolean``

The value of the test parameter should be set to `true` or `false` corresponding
to the cases that the parameter is checked or not. It is also possible, but
discouraged, to use the value specified as `truevalue` or `falsevalue`.

#### ``data``

Data input parameters can be given as a file name. The file should exist in the
`test-data` folder. Multiple files can be specified as comma separated list.

#### ``select``

The value of a select parameter should be specified as the value of one of the
legal options. If more than one option is selected (`multiple="true"`) they
should be given as comma separated list. For optional selects
(`optional="true"`) the case that no option is selected can be specified with
`value=""`.

While in general it is preferred to specify the selected cases by their values it
is also possible to specify them by their name (i.e. the content of the
`option` tag that is shown to the user). One use case is a dynamic select that is
generated from a data table with two columns: name and value where the value is
a path. Since the path changes with the test environment it can not be used to
select an option for a test.

]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="collection" type="TestCollection" minOccurs="0" maxOccurs="1"/>
      <xs:element name="composite_data" type="TestCompositeData" minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="metadata" type="TestParamMetadata" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="name" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en">This value must match the name of the
associated input parameter (``param``).</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="value" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">This value must be one of the legal
values that can be assigned to an input parameter.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="value_json" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">This variant of the value parameters can be
used to load typed parameters. This string will be loaded as JSON and its type will
attempt to be preserved through API requests to Galaxy.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="ftype" type="Format">
      <xs:annotation>
        <xs:documentation xml:lang="en">This attribute name should be included
only with parameters of ``type`` ``data`` for the tool. If this
attribute name is not included, the functional test framework will attempt to
determine the data type for the input dataset using the data type sniffers.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="dbkey" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Specifies a ``dbkey`` value for the
referenced input dataset. This is only valid if the corresponding parameter is
of ``type`` ``data``.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="tags" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Comma separated list of tags to apply to the dataset (only works for elements of collections - e.g. ``element`` XML tags).</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="location" type="xs:anyURI" gxdocs:added="23.1">
      <xs:annotation>
        <xs:documentation xml:lang="en">URL that points to a remote input file that will be downloaded and used as input.
Please use this option only when is not possible to include the files in the `test-data` folder, since
this is more error prone due to external factors like remote availability.
You can use it in two ways:
- If only ``location`` is given (and `value` is absent), the input file will be uploaded directly to Galaxy from the URL specified by the ``location``  (same as regular pasted URL upload).
- If ``location`` as well as ``value`` are given, the input file specified in ``value`` will be used from the tes data directory, if it's not available on disk it will use the ``location`` to upload the input as the previous case.
</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="TestCompositeData">
    <xs:annotation>
      <xs:documentation xml:lang="en">Define extra composite input files for test
input. The specified ``ftype`` on the parent ``param`` should specify a composite
datatype with defined static composite files. The order of the defined composite
files on the datatype must match the order specified with these elements and All
non-optional composite inputs must be specified as part of the ``param``.
</xs:documentation>
    </xs:annotation>
    <xs:attribute name="value" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en">Path relative to test-data of composite file.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="TestCollection">
    <xs:annotation>
      <xs:documentation xml:lang="en">Definition of a collection for test input.</xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="element" type="TestParam" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="type" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en">Type of collection to create.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="name" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">The identifier of the collection. Default is ``"Unnamed Collection"``</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="tags" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Comma separated list of tags to apply to the dataset (only works for elements of collections - e.g. ``element`` XML tags).</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="TestOutput">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

This tag set defines the variable that names the output dataset for the
functional test framework. The functional test framework will execute the tool
using the parameters defined in the ``<param>`` tag sets and generate a
temporary file, which will either be compared with the file named in the
``file`` attribute value or checked against assertions made by a child
``assert_contents`` tag to verify that the tool is functionally correct.

Different methods can be chosen for the comparison with the local file specified
by ``file`` using the ``compare`` attribute:

- ``diff``: uses diff to compare the history data set and the file provided by
  ``file``. Compressed files are decompressed before the comparison if
  ``decompress`` is set to ``true``. BAM files are converted to SAM before the
  comparision and for pdf some special rules are implemented. The number of
  allowed differences can be set with ``lines_diff``.  If ``sort="true"`` history
  and local data is sorted before the comparison.
- ``re_match``: each line of the history data set is compared to the regular
  expression specified in the corresponding line of the ``file``. The allowed
  number of non matching lines can be set with ``lines_diff`` and the history
  dataset is sorted if ``sort`` is set to ``true``.
- ``re_match_multiline``: it is checked if the history data sets matches the
  multi line regular expression given in ``file``. The history dataset is sorted
  before the comparison if the ``sort`` atrribute is set to ``true``.
- ``contains``: check if each line in ``file`` is contained in the history data set.
  The allowed number of lines that are not contained in the history dataset
  can be set with ``lines_diff``.
- ``sim_size``: compares the size of the history dataset and the ``file`` subject to
  the values of the ``delta`` and ``delta_frac`` attributes. Note that a ``has_size``
  content assertion should be preferred, because this avoids storing the test file.
- ``image_diff``: compares the pixel data of the history data set and the file
  provided by ``file``. The difference of the images is quantified according to their
  pixel-wise distance with respect to a specific ``metric``. The check passes if the
  distance is not larger than the value set for ``eps``. Only 2-D images can be used.

        ]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:group ref="TestOutputElement" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <!-- TODO: This would be more percise if this was required if at the top-level. -->
    <xs:attribute name="name" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[

This value is the same as the value of the ``name`` attribute of the ``<data>``
tag set contained within the tool's ``<outputs>`` tag set.

]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="file" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[

If specified, this value is the name of the output file stored in the target
``test-data`` directory which will be used to compare the results of executing
the tool via the functional test framework.

]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="value_json" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[

If specified, this value will be loaded as JSON and compared against the output
generated as JSON. This can be useful for testing tool outputs that are not files.

]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="ftype" type="Format">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[

If specified, this value will be checked against the corresponding output's
data type. If these do not match, the test will fail.

]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="sort" type="PermissiveBoolean">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[

Applies only if ``compare`` is ``diff``, ``re_match`` or ``re_match_multiline``. This flag causes the lines of the history data set to be sorted before the comparison. In case of ``diff`` and ``re_match`` also the local file is sorted. This could be
useful for non-deterministic output.

]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="value" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">An alias for ``file``.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="md5" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[

If specified, the target output's MD5 hash should match the value specified
here. For large static files it may be inconvenient to upload the entire file
and this can be used instead.

]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="checksum" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[

If specified, the target output's checksum should match the value specified
here. This value should have the form ``hash_type$hash_value``
(e.g. ``sha1$8156d7ca0f46ed7abac98f82e36cfaddb2aca041``). For large static files
it may be inconvenient to upload the entire file and this can be used instead.

]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="compare" type="TestOutputCompareType">
    </xs:attribute>
    <xs:attribute name="lines_diff" type="xs:integer">
      <xs:annotation>
        <xs:documentation xml:lang="en">Applies only if ``compare`` is set to ``diff``, ``re_match``, and ``contains``. If ``compare`` is set to ``diff``, the number of lines of difference to allow (each line with a modification is a line added and a line removed so this counts as two lines).</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="decompress" type="PermissiveBoolean">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
If this attribute is true then try to decompress files if needed. This applies to
test assertions expressed with ``assert_contents`` or ``compare`` set to anything
but ``sim_size``.
This flag is useful for testing compressed outputs that are non-deterministic
despite having deterministic decompressed contents. By default, only files compressed
with bz2, gzip and zip will be automatically decompressed.
Note, for specifying assertions for compressed as well as decompressed output
the corresponding output tag can be specified multiple times.
This is available in Galaxy since release 17.05 and was introduced in [pull request #3550](https://github.com/galaxyproject/galaxy/pull/3550).
]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="delta" type="xs:integer" default="10000">
      <xs:annotation>
        <xs:documentation xml:lang="en">If ``compare`` is set to ``sim_size``, this is the maximum allowed absolute size difference (in bytes) between the data set that is generated in the test and the file in ``test-data/`` that is referenced by the ``file`` attribute. Default value is 10000 bytes. Can be combined with ``delta_frac``.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="delta_frac" type="xs:float">
      <xs:annotation>
        <xs:documentation xml:lang="en">If ``compare`` is set to ``sim_size``, this is the maximum allowed relative size difference between the data set that is generated in the test and the file in ``test-data/`` that is referenced by the ``file`` attribute. A value of 0.1 means that the file that is generated in the test can differ by at most 10% of the file in ``test-data``. The default is not to check for  relative size difference. Can be combined with ``delta``.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="count" type="xs:integer">
      <xs:annotation>
        <xs:documentation xml:lang="en">Number or datasets for this output. Should be used for outputs with ``discover_datasets``</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="location" type="xs:anyURI" gxdocs:added="23.1">
      <xs:annotation>
        <xs:documentation xml:lang="en">URL that points to a remote output file that will downloaded and used for output comparison.
Please use this option only when is not possible to include the files in the `test-data` folder, since
this is more error prone due to external factors like remote availability.
You can use it in two ways:
- In combination with `file` it will look for the output file in the `test-data` folder, if it's not available on disk it will
download the file pointed by `location` using the same name as in `file` (or `value`).
- Specifiying the `location` without a `file` (or `value`), it will download the file and use it as an alias of `file`. The name of the file
will be infered from the last component of the location URL. For example, `location="https://my_url/my_file.txt"` will be equivalent to `file="my_file.txt"`.
If you specify a `checksum`, it will be also used to check the integrity of the download.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="metric" type="TestOutputMetricType" default="mae">
    </xs:attribute>
    <xs:attribute name="eps" type="xs:float" default="0.01">
      <xs:annotation>
        <xs:documentation xml:lang="en">If ``compare`` is set to ``image_diff``, this is the maximum allowed distance between the data set that is generated in the test and the file in ``test-data/`` that is referenced by the ``file`` attribute, with distances computed with respect to the specified ``metric``. Default value is 0.01.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="pin_labels" type="xs:string" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en">If ``compare`` is set to ``image_diff`` and ``metric`` is set to ``iou``, by default, object correspondances are established by maximizing the pairwise intersection over the union. If, however, the label of an object is listed in ``pin_labels``, then the corresponding object is determined according to the same label value (and that object cannot be the corresponding object of any other object with a different label).</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:group name="TestOutputElement">
    <xs:choice>
      <xs:element name="element" type="TestOutput"/>
      <!-- TODO: This would be more precise if this was only allowed at the top-level. -->
      <xs:element name="discovered_dataset" type="TestDiscoveredDataset"/>
      <!-- TODO: To be more precise only one assert_contents is allowed - this should not be in here. -->
      <xs:element name="assert_contents" type="TestAssertions">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[
$assertions

### Examples

The following demonstrates a wide variety of text-based and tabular
assertion statements.

```xml
<output name="out_file1">
    <assert_contents>
        <has_text text="chr7" />
        <not_has_text text="chr8" />
        <has_text_matching expression="1274\d+53" />
        <has_line_matching expression=".*\s+127489808\s+127494553" />
        <!-- &#009; is XML escape code for tab -->
        <has_line line="chr7&#009;127471195&#009;127489808" />
        <has_n_columns n="3" />
    </assert_contents>
</output>
```

The following demonstrates a wide variety of XML assertion statements.

```xml
<output name="out_file1">
    <assert_contents>
        <is_valid_xml />
        <has_element_with_path path="BlastOutput_param/Parameters/Parameters_matrix" />
        <has_n_elements_with_path n="9" path="BlastOutput_iterations/Iteration/Iteration_hits/Hit/Hit_num" />
        <element_text_matches path="BlastOutput_version" expression="BLASTP\s+2\.2.*" />
        <element_text_is path="BlastOutput_program" text="blastp" />
        <element_text path="BlastOutput_iterations/Iteration/Iteration_hits/Hit/Hit_def">
            <not_has_text text="EDK72998.1" />
            <has_text_matching expression="ABK[\d\.]+" />
        </element_text>
    </assert_contents>
</output>
```

The following demonstrates verifying XML content with XPath-like expressions.

```xml
<output name="out_file1">
    <assert_contents>
        <attribute_is path="outerElement/innerElement1" attribute="foo" text="bar" />
        <attribute_matches path="outerElement/innerElement2" attribute="foo2" expression="bar\d+" />
    </assert_contents>
</output>
```

]]></xs:documentation>
        </xs:annotation>
      </xs:element>
      <!-- TODO: This would be more percise if this was only allowed at the top-level. -->
      <xs:element name="extra_files" type="TestExtraFile"/>
      <xs:element name="metadata" type="TestOutputMetadata"/>
    </xs:choice>
  </xs:group>
  <xs:complexType name="TestParamMetadata">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[
This directive specifies metadata that should be set for a test data parameter.

See [planemo documentation](https://planemo.readthedocs.io/en/latest/writing_how_do_i.html#test-metadata)
]]></xs:documentation>
    </xs:annotation>
    <xs:attribute name="name" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en">Name of the metadata element of the data parameter</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="value" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en">Value to set</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="TestOutputMetadata">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

This directive specifies a test for an output's metadata as an expected key-value pair.

### Example

The functional test tool
[tool_provided_metadata_1.xml](https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/tool_provided_metadata_1.xml)
provides a demonstration of using this tag.

```xml
<test>
  <param name="input1" value="simple_line.txt" />
  <output name="out1" file="simple_line.txt" ftype="txt">
    <metadata name="name" value="my dynamic name" />
    <metadata name="info" value="my dynamic info" />
    <metadata name="dbkey" value="cust1" />
  </output>
</test>
```
]]></xs:documentation>
    </xs:annotation>
    <xs:attribute name="name" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en">Name of the metadata element to check.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="value" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en">Expected value (as a string) of metadata value.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="TestDiscoveredDataset">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

This directive specifies a test for an output's discovered dataset. It acts as an
``output`` test tag in many ways and can define any tests of that tag (e.g.
``assert_contents``, ``value``, ``compare``, ``md5``, ``checksum``, ``metadata``, etc...).

### Example

The functional test tool
[multi_output_assign_primary.xml](https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/multi_output_assign_primary.xml)
provides a demonstration of using this tag.

```xml
<outputs>
    <data format="tabular" name="sample">
      <discover_datasets pattern="(?P&lt;designation&gt;.+)\.report\.tsv" ext="tabular" visible="true" assign_primary_output="true" />
    </data>
</outputs>
<test>
  <param name="num_param" value="7" />
  <param name="input" ftype="txt" value="simple_line.txt"/>
  <output name="sample">
    <assert_contents>
      <has_line line="1" />
    </assert_contents>
    <!-- no sample1 it was consumed by named output "sample" -->
    <discovered_dataset designation="sample2" ftype="tabular">
      <assert_contents><has_line line="2" /></assert_contents>
    </discovered_dataset>
    <discovered_dataset designation="sample3" ftype="tabular">
      <assert_contents><has_line line="3" /></assert_contents>
    </discovered_dataset>
  </output>
</test>
```

Note that this tool uses ``assign_primary_output="true"`` for ``<discover_datasets>``. Hence, the content of the first discovered dataset (which is the first in the alphabetically sorted list of discovered designations) is checked directly in the ``<output>`` tag of the test.
]]></xs:documentation>
    </xs:annotation>
    <xs:complexContent>
      <xs:extension base="TestOutput">
        <xs:attribute type="xs:string" name="designation">
          <xs:annotation>
            <xs:documentation xml:lang="en">The designation of the discovered dataset.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
  <xs:complexType name="TestExtraFile">
    <xs:annotation>
      <xs:documentation xml:lang="en">Define test for extra files on corresponding output.</xs:documentation>
    </xs:annotation>
    <xs:complexContent>
      <xs:extension base="TestOutput">
        <xs:attribute type="xs:string" name="type">
          <xs:annotation>
            <xs:documentation xml:lang="en">Extra file type (either ``file`` or ``directory``).</xs:documentation>
          </xs:annotation>
        </xs:attribute>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
  <xs:complexType name="TestOutputCollection">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

Define tests for extra datasets and metadata corresponding to an output collection.

``output_collection`` directives should specify a ``name`` and ``type``
attribute to describe the expected output collection as a whole.

Expectations about collection contents are described using child ``element``
directives. For nested collections, these child ``element`` directives may
themselves contain children.

For tools marked as having profile 20.09 or newer, the order of elements within
an ``output_collection`` declaration are meaningful. The test definition may
omit any number of elements from a collection, but the ones that are specified
will be checked against the actual resulting collection from the tool run and the
order within the collection verified.

### Examples

The [genetrack](https://github.com/galaxyproject/tools-iuc/blob/main/tools/genetrack/genetrack.xml)
tool demonstrates basic usage of an ``output_collection`` test expectation.

```xml
<test>
    <param name="input" value="genetrack_input2.gff" ftype="gff" />
    <param name="input_format" value="gff" />
    <param name="sigma" value="5" />
    <param name="exclusion" value="20" />
    <param name="up_width" value="10" />
    <param name="down_width" value="10" />
    <param name="filter" value="3" />
    <output_collection name="genetrack_output" type="list">
        <element name="s5e20u10d10F3_on_data_1" file="genetrack_output2.gff" ftype="gff" />
    </output_collection>
</test>
```

The [CWPair2](https://github.com/galaxyproject/tools-iuc/blob/main/tools/cwpair2/cwpair2.xml)
tool demonstrates that ``element``s can specify a ``compare`` attribute just
like [output](#tool-tests-test-output).

```xml
<test>
    <param name="input" value="cwpair2_input1.gff" />
    <param name="up_distance" value="25" />
    <param name="down_distance" value="100" />
    <param name="method" value="all" />
    <param name="binsize" value="1" />
    <param name="threshold_format" value="relative_threshold" />
    <param name="relative_threshold" value="0.0" />
    <param name="output_files" value="matched_pair" />
    <output name="statistics_output" file="statistics1.tabular" ftype="tabular" />
    <output_collection name="MP" type="list">
        <element name="data_MP_closest_f0u25d100_on_data_1.gff" file="closest_mp_output1.gff" ftype="gff" compare="contains"/>
        <element name="data_MP_largest_f0u25d100_on_data_1.gff" file="largest_mp_output1.gff" ftype="gff" compare="contains"/>
        <element name="data_MP_mode_f0u25d100_on_data_1.gff" file="mode_mp_output1.gff" ftype="gff" compare="contains"/>
    </output_collection>
</test>
```

The
[collection_creates_dynamic_nested](https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/collection_creates_dynamic_nested.xml)
test tool demonstrates the use of nested ``element`` directives as described
above. Notice also that it tests the output with ``assert_contents`` instead of
supplying a ``file`` attribute. Like hinted at with with ``compare`` attribute
above, the ``element`` tag can specify any of the test attributes that apply to
the [output](#tool-tests-test-output) (e.g. ``md5``, ``compare``, ``diff``,
etc...).

```xml
<test>
  <param name="foo" value="bar" />
  <output_collection name="list_output" type="list:list">
    <element name="oe1">
      <element name="ie1">
        <assert_contents>
          <has_text_matching expression="^A\n$" />
        </assert_contents>
      </element>
      <element name="ie2">
        <assert_contents>
          <has_text_matching expression="^B\n$" />
        </assert_contents>
      </element>
    </element>
    <element name="oe2">
      <element name="ie1">
        <assert_contents>
          <has_text_matching expression="^C\n$" />
        </assert_contents>
      </element>
      <element name="ie2">
        <assert_contents>
          <has_text_matching expression="^D\n$" />
        </assert_contents>
      </element>
    </element>
    <element name="oe3">
      <element name="ie1">
        <assert_contents>
          <has_text_matching expression="^E\n$" />
        </assert_contents>
      </element>
      <element name="ie2">
        <assert_contents>
          <has_text_matching expression="^F\n$" />
        </assert_contents>
      </element>
    </element>
  </output_collection>
</test>
```

]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="element" type="TestOutput" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="name" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[

This value is the same as the value of the ``name`` attribute of the
``<collection>`` tag set contained within the tool's ``<outputs>`` tag set.

]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="type" type="CollectionType">
      <xs:annotation>
        <xs:documentation xml:lang="en">Expected collection type (``list`` or ``paired``), nested collections are specified as colon separated list (the most common types are ``list``, ``paired``, ``list:paired``, or ``list:list``).</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="count" type="xs:integer">
      <xs:annotation>
        <xs:documentation xml:lang="en">Number of elements in output collection.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="TestAssertions">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[
This tag set defines a sequence of checks or assertions to run against the
target output. This tag requires no attributes, but child tags should be used to
define the assertions to make about the output. The functional test framework
makes it easy to extend Galaxy with such tags, the following table summarizes
many of the default assertion tags that come with Galaxy and examples of each
can be found below.

The implementation of these tags are simply Python functions defined in the
[/lib/galaxy/tool_util/verify/asserts](https://github.com/galaxyproject/galaxy/tree/dev/lib/galaxy/tool_util/verify/asserts)
module.
]]></xs:documentation>
    </xs:annotation>
    <xs:choice minOccurs="0" maxOccurs="unbounded">
      <xs:group ref="TestAssertion"/>
    </xs:choice>
  </xs:complexType>
  <xs:group name="TestAssertion">
    <xs:annotation>
      <xs:documentation xml:lang="en">An individual test assertion definition.</xs:documentation>
    </xs:annotation>
    <xs:choice>
      <!--The following block and all children are auto-generated - please do not modify.-->
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.text.assert_has_line-->
      <xs:element name="has_line">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[Asserts the specified output contains the line specified by the
argument line. The exact number of occurrences can be optionally
specified by the argument n

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="line" type="xs:string" use="required">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The full line of text to search for in the output.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="n" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Desired number, can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="delta" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Allowed difference with respect to n (default: 0), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="min" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Minimum number (default: -infinity), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="max" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Maximum number (default: infinity), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="negate" type="PermissiveBoolean" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[A boolean that can be set to true to negate the outcome of the assertion.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.text.assert_has_line_matching-->
      <xs:element name="has_line_matching">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[Asserts the specified output contains a line matching the
regular expression specified by the argument expression. If n is given
the assertion checks for exactly n occurences.

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="expression" type="xs:string" use="required">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The regular expressions to attempt match in the output.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="n" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Desired number, can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="delta" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Allowed difference with respect to n (default: 0), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="min" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Minimum number (default: -infinity), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="max" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Maximum number (default: infinity), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="negate" type="PermissiveBoolean" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[A boolean that can be set to true to negate the outcome of the assertion.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.text.assert_has_n_lines-->
      <xs:element name="has_n_lines">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[Asserts the specified output contains ``n`` lines allowing
for a difference in the number of lines (delta)
or relative differebce in the number of lines

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="n" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Desired number, can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="delta" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Allowed difference with respect to n (default: 0), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="min" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Minimum number (default: -infinity), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="max" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Maximum number (default: infinity), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="negate" type="PermissiveBoolean" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[A boolean that can be set to true to negate the outcome of the assertion.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.text.assert_has_text-->
      <xs:element name="has_text">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[Asserts specified output contains the substring specified by
the argument text. The exact number of occurrences can be
optionally specified by the argument n

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="text" type="xs:string" use="required">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The text to search for in the output.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="n" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Desired number, can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="delta" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Allowed difference with respect to n (default: 0), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="min" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Minimum number (default: -infinity), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="max" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Maximum number (default: infinity), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="negate" type="PermissiveBoolean" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[A boolean that can be set to true to negate the outcome of the assertion.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.text.assert_has_text_matching-->
      <xs:element name="has_text_matching">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[Asserts the specified output contains text matching the
regular expression specified by the argument expression.
If n is given the assertion checks for exacly n (nonoverlapping)
occurences.

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="expression" type="xs:string" use="required">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The regular expressions to attempt match in the output.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="n" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Desired number, can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="delta" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Allowed difference with respect to n (default: 0), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="min" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Minimum number (default: -infinity), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="max" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Maximum number (default: infinity), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="negate" type="PermissiveBoolean" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[A boolean that can be set to true to negate the outcome of the assertion.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.text.assert_not_has_text-->
      <xs:element name="not_has_text">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[Asserts specified output does not contain the substring
specified by the argument text

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="text" type="xs:string" use="required">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The text to search for in the output.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.tabular.assert_has_n_columns-->
      <xs:element name="has_n_columns">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[Asserts tabular output  contains the specified
number (``n``) of columns.

For instance, ``<has_n_columns n="3"/>``. The assertion tests only the first line.
Number of columns can optionally also be specified with ``delta``. Alternatively the
range of expected occurences can be specified by ``min`` and/or ``max``.

Optionally a column separator (``sep``, default is ``       ``) `and comment character(s)
can be specified (``comment``, default is empty string). The first non-comment
line is used for determining the number of columns.

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="n" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Desired number, can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="delta" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Allowed difference with respect to n (default: 0), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="min" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Minimum number (default: -infinity), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="max" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Maximum number (default: infinity), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="sep" type="xs:string" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Separator defining columns, default: tab]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="comment" type="xs:string" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Comment character(s) used to skip comment lines (which should not be used for counting columns)]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="negate" type="PermissiveBoolean" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[A boolean that can be set to true to negate the outcome of the assertion.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.xml.assert_attribute_is-->
      <xs:element name="attribute_is">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[Asserts the XML ``attribute`` for the element (or tag) with the specified
XPath-like ``path`` is the specified ``text``.

For example:

```xml
<attribute_is path="outerElement/innerElement1" attribute="foo" text="bar" />
```

The assertion implicitly also asserts that an element matching ``path`` exists.
With ``negate`` the result of the assertion (on the equality) can be inverted (the
implicit assertion on the existence of the path is not affected).

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="path" type="xs:string" use="required">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The Python xpath-like expression to find the target element.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="attribute" type="xs:string" use="required">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The XML attribute name to test against from the target XML element.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="text" type="xs:string" use="required">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The expected attribute value to test against on the target XML element]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="negate" type="PermissiveBoolean" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[A boolean that can be set to true to negate the outcome of the assertion.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.xml.assert_attribute_matches-->
      <xs:element name="attribute_matches">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[Asserts the XML ``attribute`` for the element (or tag) with the specified
XPath-like ``path`` matches the regular expression specified by ``expression``.

For example:

```xml
<attribute_matches path="outerElement/innerElement2" attribute="foo2" expression="bar\d+" />
```

The assertion implicitly also asserts that an element matching ``path`` exists.
With ``negate`` the result of the assertion (on the matching) can be inverted (the
implicit assertion on the existence of the path is not affected).

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="path" type="xs:string" use="required">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The Python xpath-like expression to find the target element.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="attribute" type="xs:string" use="required">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The XML attribute name to test against from the target XML element.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="expression" type="xs:string" use="required">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The regular expressions to apply against the named attribute on the target XML element.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="negate" type="PermissiveBoolean" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[A boolean that can be set to true to negate the outcome of the assertion.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.xml.assert_element_text-->
      <xs:element name="element_text">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[This tag allows the developer to recurisively specify additional assertions as
child elements about just the text contained in the element specified by the
XPath-like ``path``, e.g.

```xml
<element_text path="BlastOutput_iterations/Iteration/Iteration_hits/Hit/Hit_def">
  <not_has_text text="EDK72998.1" />
</element_text>
```

The assertion implicitly also asserts that an element matching ``path`` exists.
With ``negate`` the result of the implicit assertions can be inverted.
The sub-assertions, which have their own ``negate`` attribute, are not affected
by ``negate``.

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:sequence>
            <xs:group ref="TestAssertion" minOccurs="1" maxOccurs="unbounded"/>
          </xs:sequence>
          <xs:attribute name="path" type="xs:string" use="required">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The Python xpath-like expression to find the target element.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="negate" type="PermissiveBoolean" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[A boolean that can be set to true to negate the outcome of the assertion.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.xml.assert_element_text_is-->
      <xs:element name="element_text_is">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[Asserts the text of the XML element with the specified XPath-like ``path`` is
the specified ``text``.

For example:

```xml
<element_text_is path="BlastOutput_program" text="blastp" />
```

The assertion implicitly also asserts that an element matching ``path`` exists.
With ``negate`` the result of the assertion (on the equality) can be inverted (the
implicit assertion on the existence of the path is not affected).

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="path" type="xs:string" use="required">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The Python xpath-like expression to find the target element.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="text" type="xs:string" use="required">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The expected element text (body of the XML tag) to test against on the target XML element]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="negate" type="PermissiveBoolean" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[A boolean that can be set to true to negate the outcome of the assertion.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.xml.assert_element_text_matches-->
      <xs:element name="element_text_matches">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[Asserts the text of the XML element with the specified XPath-like ``path``
matches the regular expression defined by ``expression``.

For example:

```xml
<element_text_matches path="BlastOutput_version" expression="BLASTP\s+2\.2.*"/>
```

The assertion implicitly also asserts that an element matching ``path`` exists.
With ``negate`` the result of the assertion (on the matching) can be inverted (the
implicit assertion on the existence of the path is not affected).

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="path" type="xs:string" use="required">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The Python xpath-like expression to find the target element.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="expression" type="xs:string" use="required">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The regular expressions to apply against the target element.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="negate" type="PermissiveBoolean" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[A boolean that can be set to true to negate the outcome of the assertion.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.xml.assert_has_element_with_path-->
      <xs:element name="has_element_with_path">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[Asserts the XML output contains at least one element (or tag) with the specified
XPath-like ``path``, e.g.

```xml
<has_element_with_path path="BlastOutput_param/Parameters/Parameters_matrix" />
```

With ``negate`` the result of the assertion can be inverted.

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="path" type="xs:string" use="required">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The Python xpath-like expression to find the target element.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="negate" type="PermissiveBoolean" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[A boolean that can be set to true to negate the outcome of the assertion.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.xml.assert_has_n_elements_with_path-->
      <xs:element name="has_n_elements_with_path">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[Asserts the XML output contains the specified number (``n``, optionally with ``delta``) of elements (or
tags) with the specified XPath-like ``path``.

For example:

```xml
<has_n_elements_with_path n="9" path="BlastOutput_iterations/Iteration/Iteration_hits/Hit/Hit_num" />
```

Alternatively to ``n`` and ``delta`` also the ``min`` and ``max`` attributes
can be used to specify the range of the expected number of occurences.
With ``negate`` the result of the assertion can be inverted.

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="path" type="xs:string" use="required">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The Python xpath-like expression to find the target element.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="n" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Desired number, can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="delta" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Allowed difference with respect to n (default: 0), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="min" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Minimum number (default: -infinity), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="max" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Maximum number (default: infinity), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="negate" type="PermissiveBoolean" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[A boolean that can be set to true to negate the outcome of the assertion.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.xml.assert_is_valid_xml-->
      <xs:element name="is_valid_xml">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[Asserts the output is a valid XML file (e.g. ``<is_valid_xml />``).

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType/>
      </xs:element>
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.xml.assert_xml_element-->
      <xs:element name="xml_element">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[Assert if the XML file contains element(s) or tag(s) with the specified
[XPath-like ``path``](https://lxml.de/xpathxslt.html).  If ``n`` and ``delta``
or ``min`` and ``max`` are given also the number of occurences is checked.

```xml
<assert_contents>
  <xml_element path="./elem"/>
  <xml_element path="./elem/more[2]"/>
  <xml_element path=".//more" n="3" delta="1"/>
</assert_contents>
```

With ``negate="true"`` the outcome of the assertions wrt the precence and number
of ``path`` can be negated. If there are any sub assertions then check them against

- the content of the attribute ``attribute``
- the element's text if no attribute is given

```xml
<assert_contents>
  <xml_element path="./elem/more[2]" attribute="name">
    <has_text_matching expression="foo$"/>
  </xml_element>
</assert_contents>
```

Sub-assertions are not subject to the ``negate`` attribute of ``xml_element``.
If ``all`` is ``true`` then the sub assertions are checked for all occurences.

Note that all other XML assertions can be expressed by this assertion (Galaxy
also implements the other assertions by calling this one).

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:sequence>
            <xs:group ref="TestAssertion" minOccurs="0" maxOccurs="unbounded"/>
          </xs:sequence>
          <xs:attribute name="path" type="xs:string" use="required">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The Python xpath-like expression to find the target element.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="attribute" type="xs:string" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The XML attribute name to test against from the target XML element.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="all" type="PermissiveBoolean" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Check the sub-assertions for all paths matching the path. Default: false, i.e. only the first ]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="n" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Desired number, can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="delta" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Allowed difference with respect to n (default: 0), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="min" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Minimum number (default: -infinity), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="max" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Maximum number (default: infinity), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="negate" type="PermissiveBoolean" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[A boolean that can be set to true to negate the outcome of the assertion.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.json.assert_has_json_property_with_text-->
      <xs:element name="has_json_property_with_text">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[Asserts the JSON document contains a property or key with the specified text (i.e. string) value.

```xml
<has_json_property_with_text property="color" text="red" />
```

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="property" type="xs:string" use="required">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The property name to search the JSON document for.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="text" type="xs:string" use="required">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The expected text value of the target JSON attribute.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.json.assert_has_json_property_with_value-->
      <xs:element name="has_json_property_with_value">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[Asserts the JSON document contains a property or key with the specified JSON value.

```xml
<has_json_property_with_value property="skipped_columns" value="[1, 3, 5]" />
```

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="property" type="xs:string" use="required">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The property name to search the JSON document for.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="value" type="xs:string" use="required">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The expected JSON value of the target JSON attribute (as a JSON encoded string).]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.hdf5.assert_has_h5_attribute-->
      <xs:element name="has_h5_attribute">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[Asserts HDF5 output contains the specified ``value`` for an attribute (``key``), e.g.

```xml
<has_h5_attribute key="nchroms" value="15" />
```

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="key" type="xs:string" use="required">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[HDF5 attribute to check value of.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="value" type="xs:string" use="required">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Expected value of HDF5 attribute to check.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.hdf5.assert_has_h5_keys-->
      <xs:element name="has_h5_keys">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[Asserts the specified HDF5 output has the given keys.

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="keys" type="xs:string" use="required">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[HDF5 attributes to check value of as a comma-separated string.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.archive.assert_has_archive_member-->
      <xs:element name="has_archive_member">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[This tag allows to check if ``path`` is contained in a compressed file.

The path is a regular expression that is matched against the full paths of the objects in
the compressed file (remember that "matching" means it is checked if a prefix of
the full path of an archive member is described by the regular expression).
Valid archive formats include ``.zip``, ``.tar``, and ``.tar.gz``. Note that
depending on the archive creation method:

- full paths of the members may be prefixed with ``./``
- directories may be treated as empty files

```xml
<has_archive_member path="./path/to/my-file.txt"/>
```

With ``n`` and ``delta`` (or ``min`` and ``max``) assertions on the number of
archive members matching ``path`` can be expressed. The following could be used,
e.g., to assert an archive containing n&plusmn;1 elements out of which at least
4 need to have a ``txt`` extension.

```xml
<has_archive_member path=".*" n="10" delta="1"/>
<has_archive_member path=".*\.txt" min="4"/>
```

In addition the tag can contain additional assertions as child elements about
the first member in the archive matching the regular expression ``path``. For
instance

```xml
<has_archive_member path=".*/my-file.txt">
  <not_has_text text="EDK72998.1"/>
</has_archive_member>
```

If the ``all`` attribute is set to ``true`` then all archive members are subject
to the assertions. Note that, archive members matching the ``path`` are sorted
alphabetically.

The ``negate`` attribute of the ``has_archive_member`` assertion only affects
the asserts on the presence and number of matching archive members, but not any
sub-assertions (which can offer the ``negate`` attribute on their own).  The
check if the file is an archive at all, which is also done by the function, is
not affected.

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:sequence>
            <xs:group ref="TestAssertion" minOccurs="0" maxOccurs="unbounded"/>
          </xs:sequence>
          <xs:attribute name="path" type="xs:string" use="required">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The regular expression specifying the archive member.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="all" type="PermissiveBoolean" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Check the sub-assertions for all paths matching the path. Default: false, i.e. only the first]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="n" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Desired number, can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="delta" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Allowed difference with respect to n (default: 0), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="min" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Minimum number (default: -infinity), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="max" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Maximum number (default: infinity), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="negate" type="PermissiveBoolean" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[A boolean that can be set to true to negate the outcome of the assertion.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.size.assert_has_size-->
      <xs:element name="has_size">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[Asserts the specified output has a size of the specified value

Attributes size and value or synonyms though value is considered deprecated.
The size optionally allows for absolute (``delta``) difference.

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="value" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Deprecated alias for `size`]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="size" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Desired size of the output (in bytes), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="delta" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Allowed difference with respect to n (default: 0), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="min" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Minimum number (default: -infinity), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="max" type="Bytes" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Maximum number (default: infinity), can be suffixed by ``(k|M|G|T|P|E)i?``]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="negate" type="PermissiveBoolean" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[A boolean that can be set to true to negate the outcome of the assertion.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.image.assert_has_image_center_of_mass-->
      <xs:element name="has_image_center_of_mass">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[Asserts the specified output is an image and has the specified center of mass.

Asserts the output is an image and has a specific center of mass,
or has an Euclidean distance of ``eps`` or less to that point (e.g.,
``<has_image_center_of_mass center_of_mass="511.07, 223.34" />``).

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="center_of_mass" type="xs:string" use="required">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The required center of mass of the image intensities (horizontal and vertical coordinate, separated by a comma).]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="channel" type="xs:integer" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Restricts the assertion to a specific channel of the image (where ``0`` corresponds to the first image channel).]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="slice" type="xs:integer" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Restricts the assertion to a specific slice of the image (where ``0`` corresponds to the first image slice).]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="frame" type="xs:integer" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Restricts the assertion to a specific frame of the image sequence (where ``0`` corresponds to the first image frame).]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="eps" type="xs:float" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The maximum allowed Euclidean distance to the required center of mass (defaults to ``0.01``).]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.image.assert_has_image_channels-->
      <xs:element name="has_image_channels">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[Asserts the output is an image and has a specific number of channels.

The number of channels is plus/minus ``delta`` (e.g., ``<has_image_channels channels="3" />``).

Alternatively the range of the expected number of channels can be specified by ``min`` and/or ``max``.

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="channels" type="xs:nonNegativeInteger" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Expected number of channels of the image.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="delta" type="xs:nonNegativeInteger" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Maximum allowed difference of the number of channels (default is 0). The observed number of channels has to be in the range ``value +- delta``.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="min" type="xs:nonNegativeInteger" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Minimum allowed number of channels.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="max" type="xs:nonNegativeInteger" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Maximum allowed number of channels.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="negate" type="PermissiveBoolean" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[A boolean that can be set to true to negate the outcome of the assertion.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.image.assert_has_image_depth-->
      <xs:element name="has_image_depth">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[Asserts the output is an image and has a specific depth (number of slices).

The depth is plus/minus ``delta`` (e.g., ``<has_image_depth depth="512" delta="2" />``).
Alternatively the range of the expected depth can be specified by ``min`` and/or ``max``.

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="depth" type="xs:nonNegativeInteger" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Expected depth of the image (number of slices).]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="delta" type="xs:nonNegativeInteger" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Maximum allowed difference of the image depth (number of slices, default is 0). The observed depth has to be in the range ``value +- delta``.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="min" type="xs:nonNegativeInteger" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Minimum allowed depth of the image (number of slices).]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="max" type="xs:nonNegativeInteger" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Maximum allowed depth of the image (number of slices).]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="negate" type="PermissiveBoolean" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[A boolean that can be set to true to negate the outcome of the assertion.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.image.assert_has_image_frames-->
      <xs:element name="has_image_frames">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[Asserts the output is an image and has a specific number of frames (number of time steps).

The number of frames is plus/minus ``delta`` (e.g., ``<has_image_frames depth="512" delta="2" />``).
Alternatively the range of the expected number of frames can be specified by ``min`` and/or ``max``.

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="frames" type="xs:nonNegativeInteger" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Expected number of frames in the image sequence (number of time steps).]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="delta" type="xs:nonNegativeInteger" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Maximum allowed difference of the number of frames in the image sequence (number of time steps, default is 0). The observed number of frames has to be in the range ``value +- delta``.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="min" type="xs:nonNegativeInteger" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Minimum allowed number of frames in the image sequence (number of time steps).]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="max" type="xs:nonNegativeInteger" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Maximum allowed number of frames in the image sequence (number of time steps).]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="negate" type="PermissiveBoolean" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[A boolean that can be set to true to negate the outcome of the assertion.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.image.assert_has_image_height-->
      <xs:element name="has_image_height">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[Asserts the output is an image and has a specific height (in pixels).

The height is plus/minus ``delta`` (e.g., ``<has_image_height height="512" delta="2" />``).
Alternatively the range of the expected height can be specified by ``min`` and/or ``max``.

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="height" type="xs:nonNegativeInteger" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Expected height of the image (in pixels).]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="delta" type="xs:nonNegativeInteger" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Maximum allowed difference of the image height (in pixels, default is 0). The observed height has to be in the range ``value +- delta``.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="min" type="xs:nonNegativeInteger" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Minimum allowed height of the image (in pixels).]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="max" type="xs:nonNegativeInteger" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Maximum allowed height of the image (in pixels).]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="negate" type="PermissiveBoolean" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[A boolean that can be set to true to negate the outcome of the assertion.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.image.assert_has_image_mean_intensity-->
      <xs:element name="has_image_mean_intensity">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[Asserts the output is an image and has a specific mean intensity value.

The mean intensity value is plus/minus ``eps`` (e.g., ``<has_image_mean_intensity mean_intensity="0.83" />``).
Alternatively the range of the expected mean intensity value can be specified by ``min`` and/or ``max``.

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="channel" type="xs:integer" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Restricts the assertion to a specific channel of the image (where ``0`` corresponds to the first image channel).]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="slice" type="xs:integer" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Restricts the assertion to a specific slice of the image (where ``0`` corresponds to the first image slice).]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="frame" type="xs:integer" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Restricts the assertion to a specific frame of the image sequence (where ``0`` corresponds to the first image frame).]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="mean_intensity" type="xs:float" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The required mean value of the image intensities.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="eps" type="xs:float" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The absolute tolerance to be used for ``value`` (defaults to ``0.01``). The observed mean value of the image intensities has to be in the range ``value +- eps``.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="min" type="xs:float" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[A lower bound of the required mean value of the image intensities.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="max" type="xs:float" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[An upper bound of the required mean value of the image intensities.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.image.assert_has_image_mean_object_size-->
      <xs:element name="has_image_mean_object_size">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[Asserts the output is an image with labeled objects which have the specified mean size (number of pixels),

The mean size is plus/minus ``eps`` (e.g., ``<has_image_mean_object_size mean_object_size="111.87" exclude_labels="0" />``).

The labels must be unique.

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="channel" type="xs:integer" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Restricts the assertion to a specific channel of the image (where ``0`` corresponds to the first image channel).]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="slice" type="xs:integer" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Restricts the assertion to a specific slice of the image (where ``0`` corresponds to the first image slice).]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="frame" type="xs:integer" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Restricts the assertion to a specific frame of the image sequence (where ``0`` corresponds to the first image frame).]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="labels" type="xs:string" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[List of labels, separated by a comma. Labels *not* on this list will be excluded from consideration. Cannot be used in combination with ``exclude_labels``.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="exclude_labels" type="xs:string" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[List of labels to be excluded from consideration, separated by a comma. The primary usage of this attribute is to exclude the background of a label image. Cannot be used in combination with ``labels``.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="mean_object_size" type="xs:float" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The required mean size of the uniquely labeled objects.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="eps" type="xs:float" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[The absolute tolerance to be used for ``value`` (defaults to ``0.01``). The observed mean size of the uniquely labeled objects has to be in the range ``value +- eps``.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="min" type="xs:float" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[A lower bound of the required mean size of the uniquely labeled objects.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="max" type="xs:float" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[An upper bound of the required mean size of the uniquely labeled objects.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.image.assert_has_image_n_labels-->
      <xs:element name="has_image_n_labels">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[Asserts the output is an image and has the specified labels.

Labels can be a number of labels or unique values (e.g.,
``<has_image_n_labels n="187" exclude_labels="0" />``).

The primary usage of this assertion is to verify the number of objects in images with uniquely labeled objects.

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="channel" type="xs:integer" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Restricts the assertion to a specific channel of the image (where ``0`` corresponds to the first image channel).]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="slice" type="xs:integer" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Restricts the assertion to a specific slice of the image (where ``0`` corresponds to the first image slice).]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="frame" type="xs:integer" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Restricts the assertion to a specific frame of the image sequence (where ``0`` corresponds to the first image frame).]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="labels" type="xs:string" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[List of labels, separated by a comma. Labels *not* on this list will be excluded from consideration. Cannot be used in combination with ``exclude_labels``.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="exclude_labels" type="xs:string" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[List of labels to be excluded from consideration, separated by a comma. The primary usage of this attribute is to exclude the background of a label image. Cannot be used in combination with ``labels``.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="n" type="xs:nonNegativeInteger" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Expected number of labels.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="delta" type="xs:nonNegativeInteger" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Maximum allowed difference of the number of labels (default is 0). The observed number of labels has to be in the range ``value +- delta``.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="min" type="xs:nonNegativeInteger" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Minimum allowed number of labels.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="max" type="xs:nonNegativeInteger" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Maximum allowed number of labels.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="negate" type="PermissiveBoolean" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[A boolean that can be set to true to negate the outcome of the assertion.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <!-- XSD doc for element auto-generated from galaxy.tool_util.verify.asserts.image.assert_has_image_width-->
      <xs:element name="has_image_width">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[Asserts the output is an image and has a specific width (in pixels).

The width is plus/minus ``delta`` (e.g., ``<has_image_width width="512" delta="2" />``).
Alternatively the range of the expected width can be specified by ``min`` and/or ``max``.

$attribute_list::5]]></xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="width" type="xs:nonNegativeInteger" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Expected width of the image (in pixels).]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="delta" type="xs:nonNegativeInteger" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Maximum allowed difference of the image width (in pixels, default is 0). The observed width has to be in the range ``value +- delta``.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="min" type="xs:nonNegativeInteger" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Minimum allowed width of the image (in pixels).]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="max" type="xs:nonNegativeInteger" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[Maximum allowed width of the image (in pixels).]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="negate" type="PermissiveBoolean" use="optional">
            <xs:annotation>
              <xs:documentation xml:lang="en"><![CDATA[A boolean that can be set to true to negate the outcome of the assertion.]]></xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
    </xs:choice>
  </xs:group>
  <xs:complexType name="Inputs">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[Consists of all elements that define the
tool's input parameters. Each [param](#tool-inputs-param) element contained in this element
can be used as a command line parameter within the [command](#tool-command) text content. Most
tools will not need to specify any attributes on this tag itself.]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:group ref="InputElement" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="action" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">URL used by data source tools.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="check_values" type="PermissiveBoolean" default="true">
      <xs:annotation>
        <xs:documentation xml:lang="en">Set to ``false`` to disable parameter checking in data source tools.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="method" type="URLmethodType">
      <xs:annotation>
        <xs:documentation xml:lang="en">*Deprecated* and ignored,
use a [request_param](#tool-request-param-translation-request-param) element with ``galaxy_name="URL_method"`` instead.
Data source HTTP action (e.g. ``get`` or ``put``) to use.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="target" type="TargetType">
      <xs:annotation>
        <xs:documentation xml:lang="en">UI link target to use for data source tools (e.g. ``_top``).</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="nginx_upload" type="PermissiveBoolean" default="false">
      <xs:annotation>
        <xs:documentation xml:lang="en">This boolean indicates if this is an upload tool or not.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:group name="InputElement">
    <xs:choice>
      <xs:element name="param" type="Param"/>
      <xs:element name="repeat" type="Repeat"/>
      <xs:element name="conditional" type="Conditional"/>
      <xs:element name="section" type="Section"/>
      <xs:element name="upload_dataset" type="xs:anyType">
        <xs:annotation>
          <xs:documentation xml:lang="en">Internal, intentionally undocumented feature.</xs:documentation>
        </xs:annotation>
      </xs:element>
      <xs:element name="display" type="xs:string">
        <xs:annotation>
          <xs:documentation xml:lang="en">Documentation for display</xs:documentation>
        </xs:annotation>
      </xs:element>
    </xs:choice>
  </xs:group>
  <xs:complexType name="InputType" abstract="true">
    <xs:annotation>
      <xs:documentation xml:lang="en">Documentation for InputType</xs:documentation>
    </xs:annotation>
    <xs:sequence/>
  </xs:complexType>
  <xs:complexType name="Conditional">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

This is a container for conditional parameters in the tool (must contain ``when``
tag sets) - the command line is then wrapped in an if-else statement.

Note that value of a conditional cannot be changed on the workflow run form.
If you expect users to interact with the element during runtime consider using ``sections`` instead.

An example tool that demonstrates conditional parameters is
[biom_convert.xml](https://github.com/galaxyproject/tools-iuc/blob/main/tools/biom_format/biom_convert.xml).

```xml
<conditional name="input_type">
    <param name="input_type_selector" type="select" label="Choose the source BIOM format">
        <option value="tsv" selected="true">Tabular File</option>
        <option value="biom">BIOM File</option>
    </param>
    <when value="tsv">
        <param name="input_table" type="data" format="tabular" label="Tabular File" argument="--input-fp"/>
        <param argument="--process-obs-metadata" type="select" label="Process metadata associated with observations when converting">
            <option value="" selected="true">Do Not process metadata</option>
            <option value="taxonomy">taxonomy</option>
            <option value="naive">naive</option>
            <option value="sc_separated">sc_separated</option>
        </param>
    </when>
    <when value="biom">
        <param name="input_table" type="data" format="biom1" label="Tabular File" argument="--input-fp"/>
    </when>
</conditional>
```

The first directive following the conditional is a [param](#tool-inputs-param),
this param must be of type ``select`` or ``boolean``. Depending on the value a
user selects for this "test" parameter - different UI elements will be shown.
These different paths are described by the following the ``when`` blocks shown
above.

The following Cheetah block demonstrates the use of the ``conditional``
shown above:

```
biom convert -i "${input_type.input_table}" -o "${output_table}"
#if str($input_type.input_type_selector) == "tsv":
    #if $input_type.process_obs_metadata:
        --process-obs-metadata "${input_type.process_obs_metadata}"
    #end if
#end if
```

Notice that the parameter ``input_table`` appears down both ``when`` clauses
so ``${input_type.input_table}`` appears unconditionally but we need to
conditionally reference ``${input_type.process_obs_metadata}`` with a Cheetah
``if`` statement.

A common use of the conditional wrapper is to select between reference data
managed by the Galaxy admins (for instance via
[data managers](https://galaxyproject.org/admin/tools/data-managers/)
) and
history files. A good example tool that demonstrates this is
the [Bowtie 2](https://github.com/galaxyproject/tools-iuc/blob/main/tools/bowtie2/bowtie2_wrapper.xml) wrapper.

```xml
<conditional name="reference_genome">
  <param name="source" type="select" label="Will you select a reference genome from your history or use a built-in index?" help="Built-ins were indexed using default options. See `Indexes` section of help below">
    <option value="indexed">Use a built-in genome index</option>
    <option value="history">Use a genome from the history and build index</option>
  </param>
  <when value="indexed">
    <param name="index" type="select" label="Select reference genome" help="If your genome of interest is not listed, contact the Galaxy team">
      <options from_data_table="bowtie2_indexes">
        <filter type="sort_by" column="2"/>
      </options>
      <validator type="no_options" message="No indexes are available for the selected input dataset"/>
    </param>
  </when>
  <when value="history">
    <param name="own_file" type="data" format="fasta" label="Select reference genome" />
  </when>
</conditional>
```

The Bowtie 2 wrapper also demonstrates other conditional paths - such as choosing
between paired inputs of single stranded inputs.
]]></xs:documentation>
    </xs:annotation>
    <xs:complexContent>
      <xs:extension base="InputType">
        <xs:sequence>
          <xs:element name="param" type="Param" minOccurs="1" maxOccurs="1"/>
          <xs:element name="when" type="ConditionalWhen" minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute name="name" type="xs:string" use="required">
          <xs:annotation>
            <xs:documentation xml:lang="en">Name for this element</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="value_from" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en"><![CDATA[Infrequently used option to dynamically access Galaxy internals, this should be avoided.

Galaxy method to execute.]]></xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="value_ref" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en"><![CDATA[Infrequently used option to dynamically access Galaxy internals, this should be avoided.

Referenced parameter to pass method.]]></xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="value_ref_in_group" type="PermissiveBoolean">
          <xs:annotation>
            <xs:documentation xml:lang="en"><![CDATA[Infrequently used option to dynamically access Galaxy internals, this should be avoided.

Is referenced parameter in the same group.]]></xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="label" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en">Human readable description for the conditional, unused in the Galaxy UI currently.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
  <xs:complexType name="ConditionalWhen">
    <xs:annotation>
      <xs:documentation xml:lang="en">This directive describes one potential
set of input for the tool at this depth. See documentation for the
[conditional](#tool-inputs-conditional) block for more details and examples (XML
and corresponding Cheetah conditionals).</xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:group ref="InputElement" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="value" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en">Value for the tool form test parameter
corresponding to this ``when`` block.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="Repeat">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[
See
[xy_plot.xml](https://github.com/galaxyproject/tools-devteam/blob/main/tools/xy_plot/xy_plot.xml)
for an example of how to use this tag set. This is a container for any tag sets
that can be contained within the ``<inputs>`` tag set. When this is used, the
tool will allow the user to add any number of additional sets of the contained
parameters (an option to add new iterations will be displayed on the tool form).
All input parameters contained within the ``<repeat>`` tag can be retrieved by
enumerating over ``$<name_of_repeat_tag_set>`` in the relevant Cheetah code.
This returns the rank and the parameter objects of the repeat container. See the
Cheetah code below.

### Example

This part is contained in the ``<inputs>`` tag set.

```xml
<repeat name="series" title="Series">
    <param name="input" type="data" format="tabular" label="Dataset"/>
    <param name="xcol" type="data_column" data_ref="input" label="Column for x axis"/>
    <param name="ycol" type="data_column" data_ref="input" label="Column for y axis"/>
</repeat>
```

This Cheetah code can be used in the ``<command>`` tag set or the
``<configfile>`` tag set.

```
#for $i, $s in enumerate($series)
    rank_of_series=$i
    input_path='${s.input}'
    x_colom=${s.xcol}
    y_colom=${s.ycol}
#end for
```

### Testing

This is an example test case with multiple repeat elements for the example above.

```xml
<test>
    <repeat name="series">
        <param name="input" value="tabular1.tsv" ftype="tabular"/>
        <param name="xcol" value="1"/>
        <param name="ycol" value="2"/>
    </repeat>
    <repeat name="series">
        <param name="input" value="tabular2.tsv" ftype="tabular"/>
        <param name="xcol" value="4"/>
        <param name="ycol" value="2"/>
    </repeat>
    <output name="out_file1" file="cool.pdf" ftype="pdf" />
</test>
```

See the documentation on the [repeat test directive](#tool-tests-test-repeat).

An older way to specify repeats in a test is by instances that are created by referring to names with a special format: ``<repeat name>_<repeat index>|<param name>``

```xml
<test>
    <param name="series_0|input" value="tabular1.tsv" ftype="tabular"/>
    <param name="series_0|xcol" value="1"/>
    <param name="series_0|ycol" value="2"/>
    <param name="series_1|input" value="tabular2.tsv" ftype="tabular"/>
    <param name="series_1|xcol" value="4"/>
    <param name="series_1|ycol" value="2"/>
    <output name="out_file1" file="cool.pdf" ftype="pdf" />
</test>
```

The test tool [disambiguate_repeats.xml](https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/disambiguate_repeats.xml)
demonstrates both testing strategies.

]]></xs:documentation>
    </xs:annotation>
    <xs:complexContent>
      <xs:extension base="InputType">
        <xs:sequence>
          <xs:group ref="InputElement" minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute name="name" type="xs:string" use="required">
          <xs:annotation>
            <xs:documentation xml:lang="en">Name for this element</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="title" type="xs:string" use="required">
          <xs:annotation>
            <xs:documentation xml:lang="en">The title of the repeat section, which will be displayed on the tool form.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="min" type="xs:integer">
          <xs:annotation>
            <xs:documentation xml:lang="en">The minimum number of repeat units.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="max" type="xs:integer">
          <xs:annotation>
            <xs:documentation xml:lang="en">The maximum number of repeat units.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="default" type="xs:integer" default="1">
          <xs:annotation>
            <xs:documentation xml:lang="en">The default number of repeat units.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="help" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en">Short help description for repeat element.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
  <xs:complexType name="Section">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[
This tag is used to group parameters into sections of the interface. Sections
are implemented to replace the commonly used tactic of hiding advanced options
behind a conditional, with sections you can easily visually group a related set
of options.

### Example

The XML configuration is relatively trivial for sections:

```xml
<inputs>
    <section name="section_name" title="Section Title" >
        <param name="parameter_name" type="text" label="A parameter  label" />
    </section>
</inputs>
```

In your command template, you'll need to include the section name to access the
variable:

```
$section_name.parameter_name
```

In output filters sections are represented as dictionary with the same name as the section:

```
<filter>section_name['parameter_name']</filter>
```

In order to reference parameters in sections from tags in the `<outputs>` section, e.g. in the `format_source` attribute of `<data>` tags, the syntax is currently:

```
<data name="output" format_source="parameter_name" metadata_source="parameter_name"/>
```

Note that references to other parameters in the `<inputs>` section are only possible if the reference is in the same section or its parents (and is defined earlier), therefore only `parameter_name` is used.

```
    <param name="foo" type="data" format="tabular"/>
    <param name="bar" type="data_column" data_ref="foo"/>
    <section>
        <param name="qux" type="data_column" data_ref="foo"/>
        <param name="foo" type="data" format="tabular"/>
        <param name="baz" type="data_column" data_ref="foo"/>
    </section>
```

In the above example `bar` and `qux` will refer to the first foo outside of the section and `baz` to the `foo` inside the section. This illustrates why non-unique parameter names are strongly discouraged.

The following will not work:

```
    <section>
        <param name="foo" type="data" format="tabular"/>
    </section>
    <param name="bar" type="data_column" data_ref="foo"/>
```

Further examples can be found in the [test case](https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/section.xml) from [pull request #35](https://github.com/galaxyproject/galaxy/pull/35).
]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:group ref="InputElement" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="name" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en">The internal key used for the section.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="title" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en">Human readable label for the section.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="expanded" type="PermissiveBoolean" default="false">
      <xs:annotation>
        <xs:documentation xml:lang="en">Whether the section should be expanded by default or not. If not, the default set values are used.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="help" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Short help description for section, rendered just below the section.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="Param">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

Contained within the ``<inputs>`` tag set - each of these specifies a field that
will be displayed on the tool form. Ultimately, the values of these form fields
will be passed as the command line parameters to the tool's executable.

### Common Attributes

The attributes valid for this tag vary wildly based on the ``type`` of the
parameter being described. All the attributes for the ``param`` element are
documented below for completeness, but here are the common ones for each
type are as follows:

$attribute_list:name,type,optional,label,help,argument,refresh_on_change:4

### Parameter Types

#### ``text``

When ``type="text"``, the parameter is free form text and appears as a text box
in the tool form.

##### Examples

Sometimes you need labels for data or graph axes, chart titles, etc. This can be
done using a text field. The following will create a text box with the default
value of "V1".

```xml
<param name="xlab" type="text" value="V1" label="Label for x axis" />
```

Unlike other types of parameters, type="text" parameters are always optional, and tool
author need to restrict the input with validator elements. By using a profile of at
least 23.0 text parameters that set ``optional="false"`` or define a validator are
indicated as required, but without validator the tool can be executed in any case.
That is a mandatory text parameter should be implemented as:

```
  <param name="mandatory" type="text" optional="false">
    <validator type="empty_field"/>
  </param>
```


The ``area`` boolean attribute can be used to change the ``text`` parameter to a
two-dimensional text area instead of a single line text box.

```xml
<param name="foo" type="text" area="true" />
```

Since release 17.01, ``text`` parameters can also supply a static list of preset
defaults options. The user **may** be presented with the option to select one of
these but will be allowed to supply an arbitrary text value.

```xml
<param name="foo" type="text" value="foo 1">
    <option value="foo 1">Foo 1 Display</option>
    <option value="foo 2">Foo 2 Display</option>
</param>
```

See [param_text_option.xml](https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/param_text_option.xml)
for a demonstration of this.

$attribute_list:value,size,area:5

#### ``integer`` and ``float``

These parameters represent whole number and real numbers, respectively.

##### Example

```xml
<param name="region_size" type="integer" value="1" label="Size of the flanking regions" />
```

$attribute_list:value,min,max:5

#### ``boolean``

This represents a binary true or false value.

$attribute_list:checked,truevalue,falsevalue:5

#### ``data``

A dataset from the current history. Multiple types might be used for the param form.

##### Examples

The following will find all "coordinate interval files" contained within the
current history and dynamically populate a select list with them. If they are
selected, their destination and internal file name will be passed to the
appropriate command line variable.

```xml
<param name="interval_file" type="data" format="interval" label="near intervals in"/>
```

The following demonstrates a ``param`` which may accept multiple files and
multiple formats.

```xml
<param format="sam,bam" multiple="true" name="bamOrSamFile" type="data"
       label="Alignments in BAM or SAM format"
       help="The set of aligned reads." />
```

Perhaps counter-intuitively, a ``multiple="true"`` data parameter requires at least one
data input. If ``optional="true"`` is specified, this condition is relaxed and the user
is allowed to select 0 datasets. Unfortunately, if 0 datasets are selected the resulting
value for the parameter during Cheetah templating (such as in a ``command`` block) will
effectively be a list with one ``None``-like entity in it.

The following idiom can be used to iterate over such a list and build a hypothetical ``-B``
parameter for each file - the ``if`` block is used to handle the case where a ``None``-like
entity appears in the list because no files were selected:

```
#for $input in $input1
    #if $input
        -B "$input"
    #end if
#end for
```

Some example tools using ``multiple="true"`` data parameters include:

- [multi_data_param.xml](https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/multi_data_param.xml)
- [multi_data_optional.xml](https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/multi_data_optional.xml)

Additionally, a detailed discussion of handling multiple homogenous files can be found in the
the [Planemo Documentation](https://planemo.readthedocs.io/en/latest/writing_advanced.html#consuming-collections)
on this topic.

$attribute_list:format,multiple,optional,min,max,load_contents:5

#### ``group_tag``

$attribute_list:multiple,date_ref:5

#### ``select``

The following will create a select list containing the options "Downstream" and
"Upstream". Depending on the selection, a ``d`` or ``u`` value will be passed to
the ``$upstream_or_down`` variable on the command line.

```xml
<param name="upstream_or_down" type="select" label="Get">
  <option value="u">Upstream</option>
  <option value="d">Downstream</option>
</param>
```

The following will create a checkbox list allowing the user to select
"Downstream", "Upstream", both, or neither. Depending on the selection, the
value of ``$upstream_or_down`` will be ``d``, ``u``, ``u,d``, or "".

```xml
<param name="upstream_or_down" type="select" label="Get" multiple="true" display="checkboxes">
  <option value="u">Upstream</option>
  <option value="d">Downstream</option>
</param>
```

$attribute_list:data_ref,dynamic_options,display,multiple:5

#### ``data_column``

This parameter type is used to select columns from a data parameter.
It uses the ``column_names`` metadata if present (only since 24.0)
and as a fallback the tab separated values of the first line.

$attribute_list:force_select,numerical,use_header_name,multiple:5

#### ``drill_down``

Allows to select values from a hierarchy. The default (``hierarchy="exact"``) is
that only exactly the selected options are used. With ``hierarchy="recurse"``
all leaf nodes in the subtree are used.

See [drill_down.xml](https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/drill_down.xml)

$attribute_list:hierarchy,multiple:5

#### ``data_collection``

The following will create a parameter that only accepts paired FASTQ files grouped into a collection.

##### Examples

```xml
<param name="inputs" type="data_collection" collection_type="paired" label="Input FASTQs" format="fastq">
</param>
```

More detailed information on writing tools that consume collections can be found
in the [planemo documentation](https://planemo.readthedocs.io/en/latest/writing_advanced.html#collections).

$attribute_list:format,collection_type:5

#### ``color``

##### Examples

The following example will create a color selector parameter.

```xml
<param name="feature_color" type="color" label="Default feature color" value="#ff00ff">
</param>
```

Given that the output includes a pound sign, it is often convenient to use a
sanitizer to prevent Galaxy from escaping the result.

```xml
<param name="feature_color" type="color" label="Default feature color" value="#ff00ff">
  <sanitizer>
    <valid initial="string.ascii_letters,string.digits">
      <add value="#" />
    </valid>
  </sanitizer>
</param>
```

$attribute_list:value,rgb:5

#### ``directory_uri``

This is used to tie into galaxy.files URI infrastructure. This should only be used by
core Galaxy tools until the interface around files has stabilized.

Currently ``directory_uri`` parameters provide user's the option of selecting a writable
directory destination for unstructured outputs of tools (e.g. history exports).

This covers examples of the most common parameter types, the remaining parameter
types are more obsecure and less likely to be useful for most tool authors.

]]></xs:documentation>
    </xs:annotation>
    <xs:complexContent>
      <xs:extension base="InputType">
        <xs:sequence>
          <xs:group ref="ParamElement" minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute name="type" type="ParamType" use="required">
          <xs:annotation>
            <xs:documentation xml:lang="en"><![CDATA[

Describes the parameter type - each different type as different semantics and
the tool form widget is different. Currently valid parameter types are:
``text``,  ``integer``,  ``float``,  ``boolean``,  ``genomebuild``,  ``select``,
``color``,  ``data_column``,  ``hidden``,  ``hidden_data``,  ``baseurl``,
``file``,  ``ftpfile``,  ``data``,  ``data_collection``,
``drill_down``. The definition of supported parameter types as defined in the
``parameter_types`` dictionary in
[/lib/galaxy/tools/parameters/basic.py](https://github.com/galaxyproject/galaxy/blob/dev/lib/galaxy/tools/parameters/basic.py).

]]></xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="name" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en"><![CDATA[Name for this element. This ``name``
is used as the Cheetah variable containing the user-supplied parameter name in
``command`` and ``configfile`` elements. The name should not contain pipes or
periods (e.g. ``.``). Some "reserved" names are ``REDIRECT_URL``,
``DATA_URL``, ``GALAXY_URL``.]]></xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <!-- TODO: add unique constraints... -->
        <xs:attribute name="area" type="PermissiveBoolean">
          <xs:annotation>
            <xs:documentation xml:lang="en">Boolean indicating if this should be
rendered as a one line text box (if ``false``, the default) or a multi-line text
 area (if ``true``). Used only when the ``type`` attribute value is ``text``.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="argument" type="xs:string">
          <xs:annotation gxdocs:best_practices="parameter-name-argument-and-help">
            <xs:documentation xml:lang="en"><![CDATA[

If the parameter reflects just one command line argument of a certain tool, this
tag should be set to that particular argument. It is rendered in parenthesis
after the help section, and it will create the name attribute (if not given explicitly)
from the argument attribute by stripping leading dashes and replacing all remaining
dashes by underscores (e.g. if ``argument="--long-parameter"`` then
``name="long_parameter"`` is implicit).

]]></xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="label" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en">The attribute value will be
displayed on the tool page as the label of the form field
(``label="Sort Query"``).</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="help" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en">Short bit of text, rendered on the
tool form just below the associated field to provide information about the
field.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="load_contents" type="xs:integer">
          <xs:annotation>
            <xs:documentation xml:lang="en">Number of bytes that should be
loaded into the `contents` attribute of the jobs dictionary provided to Expression
Tools. Used only when the ``type`` attribute value is ``data``.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="value" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en">The default value for this
parameter.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="default_value" type="xs:string" gxdocs:deprecated="true">
          <xs:annotation>
            <xs:documentation xml:lang="en">*Deprecated*. Specify default value for column parameters (use ``value`` instead).</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="optional" type="xs:string" default="false">
          <xs:annotation>
            <xs:documentation xml:lang="en">If ``false``, parameter must have a
value. Defaults to ``false`` except when the ``type`` attribute value is
``select`` and ``multiple`` is ``true``.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="rgb" type="xs:string" default="false">
          <xs:annotation>
            <xs:documentation xml:lang="en">If ``false``, the returned value
will be in Hex color code. If ``true``, it will be a RGB value e.g. ``0,0,255``.
Used only when the ``type`` attribute value is ``color``.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="min" type="xs:float">
          <xs:annotation>
            <xs:documentation xml:lang="en">Minimum valid parameter value. Used
only when the ``type`` attribute value is ``data``, ``float``, or ``integer``.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="max" type="xs:float">
          <xs:annotation>
            <xs:documentation xml:lang="en">Maximum valid parameter value. Used
only when the ``type`` attribute value is ``data``, ``float``, or ``integer``.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="format" type="FormatList">
          <xs:annotation>
            <xs:documentation xml:lang="en">The comma-separated list of accepted
data formats for this input. The list of supported data formats is contained in the
[/config/datatypes_conf.xml.sample](https://github.com/galaxyproject/galaxy/blob/dev/config/datatypes_conf.xml.sample)
file (use the file extension). Used only when the ``type`` attribute value is
``data`` or ``data_collection``.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="collection_type" type="CollectionTypeList">
          <xs:annotation>
            <xs:documentation xml:lang="en"><![CDATA[
Restrict the kind of collection that can be consumed by this parameter. Simple
collections are either ``list`` or ``paired``), nested collections are specified
as colon separated list of simple collection types (the most common types are
``list``, ``paired``, ``list:paired``, or ``list:list``). Multiple such
collection types can be specified here as a comma-separated list. Used only when
the ``type`` attribute value is ``data_collection``.
              ]]></xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="data_ref" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en"><![CDATA[
Used with select lists whose options are dynamically generated
based on certain metadata attributes of the dataset or collection upon which
this parameter depends (usually but not always the tool's input dataset).
Used only when the ``type`` attribute value is ``data_column``, ``group_tag``,
or ``select``.
            ]]></xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="accept_default" type="PermissiveBoolean">
          <xs:annotation>
            <xs:documentation xml:lang="en"><![CDATA[
Deprecated. Take the value given by ``default_value`` (or ``value``) and ``1``
if no ``value`` is given. Applies to ``data_column`` and ``group_tag``
parameters.
            ]]></xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="refresh_on_change" type="PermissiveBoolean">
          <xs:annotation>
            <xs:documentation xml:lang="en">Force a reload of the tool panel
when the value of this parameter changes to allow ``code`` file processing.
See deprecation-like notice for ``code`` blocks.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="force_select" type="PermissiveBoolean" gxdocs:deprecated="true">
          <xs:annotation>
            <xs:documentation xml:lang="en">*Deprecated*. This is the inverse of
``optional``. Set to ``false`` to not force user to select an option in the
list. Used only when the ``type`` attribute value is ``data_column``.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="use_header_names" type="PermissiveBoolean">
          <xs:annotation>
            <xs:documentation xml:lang="en">If ``true``, Galaxy assumes the
first row of ``data_ref`` is a header and builds the select list with these
values rather than the more generic ``c1`` ... ``cN`` (i.e. it will be
``c1: head1`` ... ``cN: headN``). Note that the content of the Cheetah variable
is still the column index. Used only when the ``type`` attribute value is
``data_column``.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="display" type="DisplayType">
          <xs:annotation>
            <xs:documentation xml:lang="en">Render a select list as a set of
checkboxes (``checkboxes``; note this is incompatible with ``multiple="false"``
and ``optional="false"``) or radio buttons (``radio``; note this is
incompatible with ``multiple="true"`` and ``optional="true"``). Defaults to a
drop-down menu select list. Used only when the ``type`` attribute value is
``select``.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="multiple" type="PermissiveBoolean">
          <xs:annotation>
            <xs:documentation xml:lang="en">Allow multiple values to be
selected. ``select`` parameters with ``multiple="true"`` are optional by
default. Used only when the ``type`` attribute value is ``data``, ``group_tag``,
or ``select``. Default is ``false``</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="numerical" type="PermissiveBoolean">
          <xs:annotation>
            <xs:documentation xml:lang="en">If ``true`` a data column will be
treated as numerical when filtering columns based on metadata. Used only when
the ``type`` attribute value is ``data_column``.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="hierarchy" type="HierarchyType">
          <xs:annotation>
            <xs:documentation xml:lang="en">Determine if a drill down is
``recursive`` or ``exact``. Used only when the ``type`` attribute value is
``drill_down``.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="checked" type="PermissiveBoolean" default="false">
          <xs:annotation>
            <xs:documentation xml:lang="en">Set to ``true`` if the ``boolean``
parameter should be checked (or ``true``) by default. Used only when the
``type`` attribute value is ``boolean``.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="truevalue" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en">The parameter value in the Cheetah
template if the parameter is ``true`` or checked by the user. Used only when the
``type`` attribute value is ``boolean``.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="falsevalue" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en">The parameter value in the Cheetah
template if the parameter is ``false`` or not checked by the user. Used only
when the ``type`` attribute value is ``boolean``.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="allow_uri_if_protocol" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en"><![CDATA[
When using `deferred` datasets, Galaxy will try to materialize them into files when
running the tool. In case we don't want to download them, the `allow_uri_if_protocol` attribute
can be used to avoid materialization and pass the URI as is to the tool.
This is useful when the tool can handle the URI directly. Example:

```xml
<param name="input" type="data" format="txt" allow_uri_if_protocol="http,https,s3" />
```

You can specify multiple prefixes separated by comma or use the wildcard '*' to always
treat deferred datasets as URIs. The source URI will be passed to the tool as is.

This attribute is only valid for `data` parameters.

### Handling the input in the tool

Since the input can be a regular file or a URI, the tool should be able to handle both cases.
The tool should check if the input ``is_deferred`` and if so, treat it as a URI, otherwise
it should treat it as a regular file. Please note that only deferred datasets with the specified
protocol will be passed as URIs, the rest will be materialized as files.

Here is an example command section that handles the above sample input:

```python
<command>
  ## We should handle the case where the input must be treated as a URI with a specific protocol.
  #if $input.is_deferred:
      ## Here, the input is a deferred dataset which source URI has the protocol 'https', 'http' or 's3'.
      echo '$input' > '$output' ## The ouput will be the source URI of the input.
  #else:
      ## Here, the input is a regular dataset or a materialized dataset in case of a 
      ## deferred dataset which source URI has a protocol different than 'https', 'http' or 's3'.
      cp '$input' '$output' ## The output will be a copy of the input content.
</command>
```
         ]]></xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="size" type="xs:string" gxdocs:deprecated="true">
          <!-- TODO: can be integer or integerxinteger -->
          <xs:annotation>
            <xs:documentation xml:lang="en">*Deprecated*. Completely ignored
since release 16.10. Used only when the ``type`` attribute value is ``text``.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <!-- metadata_name appears in some wrappers but I think this is a copy
             and paste problem and doesn't reflect something actually used by
             Galaxy.
        -->
        <!--
        <xs:attribute name="metadata_name" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en">Documentation for metadata_name</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        -->
        <xs:attribute name="dynamic_options" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en">Deprecated/discouraged method to
allow access to Python code to generate options for a select list. See
``code``'s documentation for an example.
</xs:documentation>
          </xs:annotation>
        </xs:attribute>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
  <xs:group name="ParamElement">
    <xs:choice>
      <xs:element name="label" type="xs:string">
        <xs:annotation>
          <xs:documentation xml:lang="en">Documentation for label</xs:documentation>
        </xs:annotation>
      </xs:element>
      <xs:element name="conversion" type="ParamConversion"/>
      <xs:element name="option" type="ParamSelectOption"/>
      <xs:element name="options" type="ParamOptions"/>
      <xs:element name="validator" type="Validator"/>
      <xs:element name="sanitizer" type="Sanitizer"/>
      <xs:element name="default" type="ParamDefault"/>
      <xs:element name="help" type="xs:string">
        <xs:annotation>
          <xs:documentation xml:lang="en">Documentation for help</xs:documentation>
        </xs:annotation>
      </xs:element>
    </xs:choice>
  </xs:group>
  <xs:simpleType name="ParamType">
    <xs:annotation>
      <xs:documentation xml:lang="en">Documentation for ParamType</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="text"/>
      <xs:enumeration value="integer"/>
      <xs:enumeration value="float"/>
      <xs:enumeration value="color"/>
      <xs:enumeration value="boolean"/>
      <xs:enumeration value="genomebuild"/>
      <xs:enumeration value="select"/>
      <xs:enumeration value="data_column"/>
      <xs:enumeration value="hidden"/>
      <xs:enumeration value="hidden_data"/>
      <xs:enumeration value="baseurl"/>
      <xs:enumeration value="file"/>
      <xs:enumeration value="data"/>
      <xs:enumeration value="drill_down"/>
      <xs:enumeration value="group_tag"/>
      <xs:enumeration value="data_collection"/>
      <xs:enumeration value="directory_uri"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:complexType name="Command">
    <xs:annotation gxdocs:best_practices="command-tag">
      <xs:documentation xml:lang="en"><![CDATA[
This tag specifies how Galaxy should invoke the tool's executable, passing its
required input parameter values (the command line specification links the
parameters supplied in the form with the actual tool executable). Any word
inside it starting with a dollar sign (``$``) will be treated as a variable whose
values can be acquired from one of three sources: parameters, metadata, or
output files. After the substitution of variables with their values, the content
is interpreted with [Cheetah](https://pythonhosted.org/Cheetah/) and finally given
to the interpreter specified in the corresponding attribute (if any).

### Examples

The following uses a compiled executable ([bedtools](https://bedtools.readthedocs.io/en/latest/)).

```xml
<command><![CDATA[
bed12ToBed6 -i '$input' > '$output'
]]]]><![CDATA[></command>
```

A few things to note about even this simple example:

* Input and output variables (boringly named ``input`` and ``output``)
  are expanded into paths using the ``$`` Cheetah directive.
* Paths should be quoted so that the Galaxy database files may contain spaces.
* We are building up a shell script - so special characters like ``>`` can be used
  (in this case the standard output of the bedtools call is written to the path
  specified by ``'$output'``).

The bed12ToBed6 tool can be found [here](https://github.com/galaxyproject/tools-iuc/blob/main/tools/bedtools/bed12ToBed6.xml).

A more sophisticated bedtools example demonstrates the use of loops, conditionals,
and uses whitespace to make a complex command very readable can be found in
[annotateBed](https://github.com/galaxyproject/tools-iuc/blob/main/tools/bedtools/annotateBed.xml)
tool.

```xml
<command><![CDATA[
bedtools annotate
-i '${inputA}'
#if $names.names_select == 'yes':
    -files
    #for $bed in $names.beds:
        '${bed.input}'
    #end for
    -names
    #for $bed in $names.beds:
        '${bed.inputName}'
    #end for
#else:
    #set files = '" "'.join([str($file) for $file in $names.beds])
    -files '${files}'
    #set names = '" "'.join([str($name.display_name) for $name in $names.beds])
    -names '${names}'
#end if
$strand
$counts
$both
> '${output}'
]]]]><![CDATA[></command>
```

The following example (taken from [xpath](https://github.com/galaxyproject/tools-iuc/blob/main/tools/xpath/xpath.xml) tool)
uses an interpreted executable. In this case a Perl script is shipped with the
tool and the directory of the tool itself is referenced with ``$__tool_directory__``.

```xml
<command><![CDATA[
perl '$__tool_directory__/xpath' -q -e '$expression' '$input' > '$output'
]]]]><![CDATA[></command>
```

The following example demonstrates accessing metadata from datasets. Metadata values
(e.g., ``${input.metadata.chromCol}``) are acquired from the ``Metadata`` model associated
with the objects selected as the values of each of the relative form field
parameters in the tool form. Accessing this information is generally enabled using
the following feature components.

A set of "metadata information" is defined for each supported data type (see the
``MetadataElement`` objects in the various data types classes in
[/lib/galaxy/datatypes](https://github.com/galaxyproject/galaxy/tree/dev/lib/galaxy/datatypes).
The ``DatasetFilenameWrapper`` class in the
[/lib/galaxy/tools/wrappers.py](https://github.com/galaxyproject/galaxy/blob/dev/lib/galaxy/tools/wrappers.py)
code file wraps a metadata collection to return metadata parameters wrapped
according to the Metadata spec.

```xml
<command><![CDATA[
        #set genome = $input.metadata.dbkey
        #set datatype = $input.datatype
        mkdir -p output_dir &&
        python '$__tool_directory__/extract_genomic_dna.py'
        --input '$input'
        --genome '$genome'
        #if $input.is_of_type("gff"):
            --input_format "gff"
            --columns "1,4,5,7"
            --interpret_features $interpret_features
        #else:
            --input_format "interval"
            --columns "${input.metadata.chromCol},${input.metadata.startCol},${input.metadata.endCol},${input.metadata.strandCol},${input.metadata.nameCol}"
        #end if
        --reference_genome_source $reference_genome_cond.reference_genome_source
        #if str($reference_genome_cond.reference_genome_source) == "cached"
            --reference_genome $reference_genome_cond.reference_genome.fields.path
        #else:
            --reference_genome $reference_genome_cond.reference_genome
        #end if
        --output_format $output_format_cond.output_format
        #if str($output_format_cond.output_format) == "fasta":
            --fasta_header_type $output_format_cond.fasta_header_type_cond.fasta_header_type
            #if str($output_format_cond.fasta_header_type_cond.fasta_header_type) == "char_delimited":
                --fasta_header_delimiter $output_format_cond.fasta_header_type_cond.fasta_header_delimiter
            #end if
        #end if
        --output '$output'
]]]]><![CDATA[></command>
```

In additon to demonstrating accessing metadata, this example demonstrates:

* ``$input.is_of_type("gff")`` which can be used to check if an input is of a
  given datatype.
* ``#set datatype = $input.datatype`` which is the syntax for defining variables
  in Cheetah.

### Reserved Variables

Galaxy provides a few pre-defined variables which can be used in your command line,
even though they don't appear in your tool's parameters.

Name | Description
---- | -----------
``$__tool_directory__`` | The directory the tool description (XML file) currently resides in (new in 15.03)
``$__new_file_path__`` | ``config/galaxy.ini``'s ``new_file_path`` value
``$__tool_data_path__`` | ``config/galaxy.ini``'s tool_data_path value
``$__root_dir__`` | Top-level Galaxy source directory made absolute via ``os.path.abspath()``
``$__datatypes_config__`` | ``config/galaxy.ini``'s datatypes_config value
``$__user_id__`` | Numeric ID of user (id column of ``galaxy_user`` table in the database)
``$__user_email__`` | Email address of the user
``$__user_name__`` | User name of the user
``$__app__`` | The ``galaxy.app.UniverseApplication`` instance, gives access to all other configuration file variables (e.g. $__app__.config.output_size_limit). Should be used as a last resort, may go away in future releases.
``$__target_datatype__`` | Only available in converter tools when run internally by Galaxy. Contains the target datatype of the conversion


Additional runtime properties are available as environment variables. Since these
are not Cheetah variables (the values aren't available until runtime) these should likely
be escaped with a backslash (``\``) when appearing in ``command`` or ``configfile`` elements.

For internal converter tools using ``$__target_datatype__`` it is recommended to add a select
input parameter with name ``__target_datatype__`` in order to make the tool testable, see
for instance the [biom converter](https://github.com/galaxyproject/galaxy/blob/dev/lib/galaxy/datatypes/converters/biom.xml).

Name | Description
---- | -----------
``\${GALAXY_SLOTS:-4}`` | Number of cores/threads allocated by the job runner or resource manager to the tool for the given job (here 4 is the default number of threads to use if running via custom runner that does not configure GALAXY_SLOTS or in an older Galaxy runtime).
``\$GALAXY_MEMORY_MB`` | Total amount of memory in megabytes (1024^2 bytes) allocated by the administrator (via the resource manager) to the tool for the given job. If unset, tools should not attempt to limit memory usage.
``\$GALAXY_MEMORY_MB_PER_SLOT`` | Amount of memory per slot in megabytes (1024^2 bytes) allocated by the administrator (via the resource manager) to the tool for the given job. If unset, tools should not attempt to limit memory usage.
``\$_GALAXY_JOB_TMP_DIR`` | Path to an empty directory in the job's working directory that can be used as a temporary directory.

See the [Planemo docs](https://planemo.readthedocs.io/en/latest/writing_advanced.html#cluster-usage)
on the topic of ``GALAXY_SLOTS`` for more information and examples.

### Error detection

The ``detect_errors`` attribute of ``command``, if present, loads a preset of error detection checks (for exit codes and content of stdio to indicate fatal tool errors or fatal out of memory errors). It can be one of:

* ``default``: for non-legacy tools with absent stdio block non-zero exit codes are added. For legacy tools or if a stdio block is present nothing is added.
* ``exit_code``: adds checks for non zero exit codes (The @jmchilton recommendation). The ``oom_exit_code`` parameter can be used to add an additional out of memory indicating exit code.
* ``aggressive``: adds checks for non zero exit codes, and checks for ``Exception:``, ``Error:`` in the standard error. Additionally checks for messages in the standard error that indicate an out of memory error (``MemoryError``, ``std::bad_alloc``, ``java.lang.OutOfMemoryError``, ``Out of memory``). (The @bgruening recommendation).

Prior to Galaxy release 19.01 the stdio block has only been used for non-legacy tools using ``default``. From release 19.01 checks defined in the stdio tag are prepended to the checks defined by the presets loaded in the command block.
]]></xs:documentation>
    </xs:annotation>
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="detect_errors" type="DetectErrorType">
          <xs:annotation>
            <xs:documentation xml:lang="en"><![CDATA[
The ``detect_errors`` attribute of ``command``, if present, loads a preset of error detection checks (for exit codes and content of stdio to indicate fatal tool errors or fatal out of memory errors). It can be one of:

* ``default``: for non-legacy tools with absent stdio block non-zero exit codes are added. For legacy tools or if a stdio block is present nothing is added.
* ``exit_code``: adds checks for non zero exit codes. The ``oom_exit_code`` parameter can be used to add an additional out of memory indicating exit code. This is the default when a tool specifies a ``profile`` >= 16.04.
* ``aggressive``: adds checks for non zero exit codes, and checks for ``Exception:``, ``Error:`` in the standard error. Additionally checks for messages in the standard error that indicate an out of memory error (``MemoryError``, ``std::bad_alloc``, ``java.lang.OutOfMemoryError``, ``Out of memory``).
]]></xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="oom_exit_code" type="xs:integer">
          <xs:annotation>
            <xs:documentation xml:lang="en">Only used if ``detect_errors="exit_code"``, tells Galaxy the specified exit code indicates an out of memory error. Galaxy instances may be configured to retry such jobs on resources with more memory.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="use_shared_home" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en">When running a job for this tool, do not isolate its ``$HOME`` directory within the job's directory - use either the ``shared_home_dir`` setting in Galaxy or the default ``$HOME`` specified in the job's default environment.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="interpreter" type="xs:string" gxdocs:deprecated="true">
          <xs:annotation>
            <xs:documentation xml:lang="en"><![CDATA[*Deprecated*. This will prefix the command with the value of this attribute (e.g. ``python`` or ``perl``) and the tool directory, in order to run an executable file shipped with the tool. It is recommended to instead use ``<interpreter> '$__tool_directory__/<executable_name>'`` in the tag content. If this attribute is not specified, the tag should contain a Bash command calling executable(s) available in the ``$PATH``, as modified after loading the requirements.]]></xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="strict" type="xs:boolean">
          <xs:annotation>
            <xs:documentation xml:lang="en">This boolean forces the ``#set -e`` directive on in shell scripts - so that in a multi-part command if any part fails the job exits with a non-zero exit code. This is enabled by default for tools with ``profile&gt;=20.09`` and disabled on legacy tools.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="Expression">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[
For "Expression Tools" (tools with ``tool_type="expression``) this block describes the expression
used to evaluate inputs and produce outputs. The semantics are going to vary based on the value
of "type" specified for this expression block.
]]></xs:documentation>
    </xs:annotation>
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="type" type="ExpressionType">
          <xs:annotation>
            <xs:documentation xml:lang="en">Type of expression defined by this expression block. The only current valid option is ecma5.1 - which will evaluate the expression in a sandbox using node. The option still must be specified to allow a different default in the future.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:simpleType name="ExpressionType">
    <xs:annotation>
      <xs:documentation xml:lang="en"/>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="ecma5.1"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="RequestMethodType">
    <xs:annotation>
      <xs:documentation xml:lang="en">Select a request method, defaults to GET if unspecified</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="GET"/>
      <xs:enumeration value="POST"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:complexType name="ParamSelectOption">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

See [/tools/filters/sorter.xml](https://github.com/galaxyproject/galaxy/blob/dev/tools/filters/sorter.xml)
for typical examples of how to use this tag set. This directive is used to described
static lists of options and is contained
within the [param](#tool-inputs-param) directive when the ``type`` attribute
value is ``select`` (i.e. ``<param type="select" ...>``).

### Example

```xml
<param name="style" type="select" label="with flavor">
    <option value="num">Numerical sort</option>
    <option value="gennum">General numeric sort</option>
    <option value="alpha">Alphabetical sort</option>
</param>
```

An option can also be annotated with ``selected="true"`` to specify a
default option (note that the first option is selected automatically
if ``optional="false"``).

```xml
<param name="col" type="select" label="From">
    <option value="0">Column 1 / Sequence name</option>
    <option value="1" selected="true">Column 2 / Source</option>
    <option value="2">Column 3 / Feature</option>
    <option value="6">Column 7 / Strand</option>
    <option value="7">Column 8 / Frame</option>
</param>
```

In general the values and the texts for the options need to be unique,
but it is possible to specify an option two times if the 2nd has a different
value for the ``selected`` attribute. This is handy if an option list is
defined in a macro and different default value(s) are used.
]]></xs:documentation>
    </xs:annotation>
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="value" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en"><![CDATA[The value of the
corresponding variable when used the Cheetah template. Also the value that
should be used in building test cases and used when building requests for the
API.]]></xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="selected" type="PermissiveBoolean" default="false">
          <xs:annotation>
            <xs:documentation xml:lang="en">A boolean parameter indicating
if the corresponding option is selected by default (the default is ``false``).
</xs:documentation>
          </xs:annotation>
        </xs:attribute>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="ParamDrillDownOption">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[
See [drill_down.xml](https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/drill_down.xml)
      ]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="option" type="ParamDrillDownOption" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="name" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en">Name of the ``drill_down`` option.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="value" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en">Value of the ``drill_down`` option.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="ParamConversion">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

A contrived example of a tool that uses this is the test tool
[explicit_conversion.xml](https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/explicit_conversion.xml).

This directive is optionally contained within the ``<param>`` tag when the
``type`` attribute value is ``data`` and is used to dynamically generated a converted
dataset for the contained input of the type specified using the ``type`` tag.

]]></xs:documentation>
    </xs:annotation>
    <xs:attribute name="name" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en">Name of Cheetah variable to create for converted dataset.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="type" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en">The short extension describing the datatype to convert to - Galaxy must have a datatype converter from the parent input's type to this.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="ParamDefault">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[
]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <!-- can have zero or one collection elements -->
      <xs:element name="element" type="ParamDefaultElement" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="collection_type" type="CollectionType" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
Collection type for default collection (if param type is data_collection). Simple collection types are
either ``list`` or ``paired``, nested collections are specified as colon separated list of simple
collection types (the most common types are ``list``, ``paired``,
``list:paired``, or ``list:list``).
        ]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="location" type="xs:anyURI" gxdocs:added="23.2" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
Galaxy-aware URI for the default file. This should only be used with parameters of type "data".
        ]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="ParamDefaultCollection">
    <xs:sequence>
      <xs:element name="element" type="ParamDefaultElement" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="collection_type" type="CollectionType" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
Collection type for default collection (if param type is data_collection). Simple collection types are
either ``list`` or ``paired``, nested collections are specified as colon separated list of simple
collection types (the most common types are ``list``, ``paired``,
``list:paired``, or ``list:list``).
        ]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="ParamDefaultElement">
    <xs:sequence>
      <xs:element name="collection" type="ParamDefaultCollection" minOccurs="0" maxOccurs="1"/>
    </xs:sequence>
    <xs:attribute name="name" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Name (and element identifier) for this element</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="location" type="xs:anyURI" gxdocs:added="23.2" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
Galaxy-aware URI for the default file for collection element.
        ]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="ParamOptions">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[
This tag set is optionally contained within the ``<param>`` tag when the
``type`` attribute value is ``select`` or ``data`` and used to dynamically
generated lists of options.
See [/tools/extract/liftOver_wrapper.xml](https://github.com/galaxyproject/galaxy/blob/dev/tools/extract/liftOver_wrapper.xml)
and [test/functional/tools/select_dynamic.xml](https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/select_dynamic.xml)
for an examples of how to use this tag set.

For data parameters this tag can be used to restrict possible input datasets to datasets that match the ``dbkey`` of another data input by including a ``data_meta`` filter. See for
instance here: [/tools/maf/interval2maf.xml](https://github.com/galaxyproject/galaxy/blob/dev/tools/maf/interval2maf.xml)

For select parameters this tag set dynamically creates a list of options whose
values can be obtained from a predefined file stored locally, a dataset
selected from the current history or data fetched from a URL.

There are at least five basic ways to use this tag - four of these correspond to
a ``from_XXX`` attribute on the ``options`` directive and the other is to
exclusively use ``filter``s to populate options.

* ``from_data_table`` - The options for the select list are dynamically obtained
  from a file specified in the Galaxy configuration file
  ``tool_data_table_conf.xml`` or from a Tool Shed installed data manager.
* `from_url` - Fetches a list of available options from a remote server.
* ``from_dataset`` - The options for the select list are dynamically obtained
  from input dataset selected for the tool from the current history.
* ``from_file`` - The options for the select list are dynamically obtained from
  a file. This mechanism is discouraged in favor of the more generic
  ``from_data_table``.
* ``from_parameter`` - The options for the select list are dynamically obtained
  from a parameter.
* Using ``filter``s - various filters can be used to populate options, see
  examples in the [filter](#tool-inputs-param-options-filter) documentation.

### ``from_data_table``

See Galaxy's
[data tables documentation](https://galaxyproject.org/admin/tools/data-tables)
for information on setting up data tables.

Once a data table has been configured and populated, these can be easily
leveraged via tools.

This ``conditional`` block in the
[bowtie2](https://github.com/galaxyproject/tools-devteam/blob/main/tools/bowtie2/bowtie2_wrapper.xml)
wrapper demonstrates using ``from_data_table`` options as an
alternative to local reference data.

```xml
<conditional name="reference_genome">
  <param name="source" type="select" label="Will you select a reference genome from your history or use a built-in index?" help="Built-ins were indexed using default options. See `Indexes` section of help below">
    <option value="indexed">Use a built-in genome index</option>
    <option value="history">Use a genome from the history and build index</option>
  </param>
  <when value="indexed">
    <param name="index" type="select" label="Select reference genome" help="If your genome of interest is not listed, contact the Galaxy team">
      <options from_data_table="bowtie2_indexes">
        <filter type="sort_by" column="2"/>
      </options>
      <validator type="no_options" message="No indexes are available for the selected input dataset"/>
    </param>
  </when>
  <when value="history">
    <param name="own_file" type="data" format="fasta" label="Select reference genome" />
  </when>
</conditional>
```

A minimal example wouldn't even need the ``filter`` or ``validator`` above, but
they are frequently nice features to add to your wrapper and can improve the user
experience of a tool.

### ``from_dataset``

The following example is taken from the Mothur tool
[remove.lineage.xml](https://github.com/galaxyproject/tools-iuc/blob/main/tools/mothur/remove.lineage.xml)
and demonstrates generating options from a dataset directly.

```xml
<param name="taxonomy" type="data" format="mothur.seq.taxonomy" label="taxonomy - Taxonomy" help="please make sure your file has no quotation marks in it"/>
<param name="taxons" type="select" optional="true" multiple="true" label="Browse Taxons from Taxonomy">
    <options from_dataset="taxonomy">
        <column name="name" index="1"/>
        <column name="value" index="1"/>
        <filter type="unique_value" name="unique_taxon" column="1"/>
        <filter type="sort_by" name="sorted_taxon" column="1"/>
    </options>
    <sanitizer>
        <valid initial="default">
            <add preset="string.printable"/>
            <add value=";"/>
            <remove value="&quot;"/>
            <remove value="&apos;"/>
        </valid>
    </sanitizer>
</param>
```

Starting from Galaxy v21.01, ``meta_file_key`` can be used together with
``from_dataset``. In such cases, options are generated using the dataset's
medadata file that the ``meta_file_key`` implies, instead of the dataset
itself.

Note that in any case only the first mega byte of the referred dataset (or file)
is considered. Lines starting with ``#`` are ignored. By using the ``startswith``
attribute also lines starting with other strings can be ignored.

```xml
<param name="input" type="data" format="maf" label="MAF File"/>
<param name="species" type="select" optional="False" label="Select species for the input dataset" multiple="True">
    <options from_dataset="input" meta_file_key="species_chromosomes">
        <column name="name" index="0"/>
        <column name="value" index="0"/>
    </options>
</param>
<param name="input_2" type="data_collection" collection_type="list" format="maf" label="MAF Collection" multiple="true" />
<param name="species_2" type="select" optional="false" label="Select species for the input dataset" multiple="true">
    <options from_dataset="input_2" meta_file_key="species_chromosomes" >
        <column name="name" index="0"/>
        <column name="value" index="0"/>
        <filter type="unique_value" name="unique_param" column="0"/>
  </options>
</param>
```

Filters can be used to generate options from dataset directly also as the
example below demonstrates (many more examples are present in the
[filter](#tool-inputs-param-options-filter) documentation).

```xml
<param name="species1" type="select" label="When Species" multiple="false">
    <options>
        <filter type="data_meta" ref="input1" key="species" />
    </options>
</param>
```

### ``from_url``

The following example demonstrates getting options from a third-party server
with server side requests.

```xml
<param name="url_param_value" type="select">
    <options from_url="https://usegalaxy.org/api/genomes">
    </options>
</param>
```

Here a GET request is made to [https://usegalaxy.org/api/genomes](https://usegalaxy.org/api/genomes), which returns
an array of arrays, such as

```json
[
    ["unspecified (?)", "?"],
    ["A. ceylanicum Mar. 2014 (WS243/Acey_2013.11.30.genDNA/ancCey1) (ancCey1)", "ancCey1"],
    ...
]
```
Each inner array is a user-selectable option, where the first item in the inner array
is the `name` of the option (as shown in the select field in the user interface), and
the second option is the `value` that is passed on to the tool. An optional third
element can be added to the inner array which corresponds to the `selected` state.
If the third item is `true` then this particular option is pre-selected.

A more complicated example is shown below, where a POST request is made with a templated
request header and body. The upstream response is then also transformed using an ecma 5.1
expression:

```xml
<param name="url_param_value_header_and_body" type="select">
    <options from_url="https://postman-echo.com/post" request_method="POST">
        <!-- Example for accessing user secrets via extra preferences -->
        <request_headers type="json">
            {"x-api-key": "${__user__.extra_preferences.fake_api_key if $__user__ else "anon"}"}
        </request_headers>
        <request_body type="json">
            {"name": "value"}
        </request_body>
        <!-- https://postman-echo.com/post echos values sent to it, so here we list the response headers -->
        <postprocess_expression type="ecma5.1"><![CDATA[${
            return Object.keys(inputs.headers).map((header) => [header, header])
        }]]]]><![CDATA[></postprocess_expression>
    </options>
</param>
```

The header and body templating mechanism can be used to access protected resources,
and the `postprocess_expression` can be used to transform arbitrary JSON responses
to arrays of `name` and `value`, or arrays of `name`, `value` and `selected`.

For an example tool see [select_from_url.xml](https://github.com/galaxyproject/galaxy/tree/dev/test/functional/tools/select_from_url.xml).

### ``from_file``

The following example is for Blast databases. In this example users maybe select
a database that is pre-formatted and cached in Galaxy clusters. When a new
dataset is available, admins must add the database to the local file named
"blastdb.loc". All such databases in that file are included in the options of
the select list. For a local instance, the file (e.g. ``blastdb.loc`` or
``alignseq.loc``) must be stored in the configured
[tool_data_path](https://github.com/galaxyproject/galaxy/tree/dev/tool-data)
directory. In this example, the option names and values are taken from column 0
of the file.

```xml
<param name="source_select" type="select" display="radio" label="Choose target database">
    <options from_file="blastdb.loc">
        <column name="name" index="0"/>
        <column name="value" index="0"/>
    </options>
</param>
```

In general, ``from_file`` should be considered deprecated and  ``from_data_table``
should be prefered.

### ``from_parameter``

This variant of the ``options`` directive is discouraged because it exposes
internal Galaxy structures. See the older
[bowtie](https://github.com/galaxyproject/tools-devteam/blob/main/tools/bowtie_wrappers/bowtie_wrapper.xml)
wrappers for an example of these.

### Other Ways to Dynamically Generate Options

Though deprecated and discouraged, [code](#tool-code) blocks can also be
used to generate dynamic options.

]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:group ref="OptionsElement" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="from_dataset" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Determine options from (the first MB of) the dataset given in the referred input parameter. If 'meta_file_key' is given, the options are determined from (the first MB of) the data in the metadata file of the input.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="from_file" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Deprecated.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="from_data_table" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Determine options from a data table. </xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="from_url" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Determine options from data hosted at specified URL. </xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="request_method" type="RequestMethodType">
      <xs:annotation>
        <xs:documentation xml:lang="en">Set the request method to use for options provided using 'from_url'. </xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="from_parameter" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Deprecated.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="options_filter_attribute" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Deprecated.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="transform_lines" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Deprecated.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="startswith" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Keep only lines starting with the given string.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="meta_file_key" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Works with from_dataset only. See [docs](#from-dataset)</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="separator" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Split tabular data with this character (default is tab)</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:group name="OptionsElement">
    <xs:choice>
      <xs:element name="filter" type="Filter" minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="column" type="Column" minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="validator" type="Validator" minOccurs="0" maxOccurs="1"/>
      <xs:element name="postprocess_expression" type="Expression" minOccurs="0" maxOccurs="1"/>
      <xs:element name="request_body" type="RequestBody" minOccurs="0" maxOccurs="1"/>
      <xs:element name="request_headers" type="RequestHeaders" minOccurs="0" maxOccurs="1"/>
      <xs:element name="file" type="xs:string" minOccurs="0" maxOccurs="unbounded">
        <xs:annotation>
          <xs:documentation xml:lang="en">Documentation for file</xs:documentation>
        </xs:annotation>
      </xs:element>
      <xs:element name="option" type="ParamDrillDownOption" minOccurs="0" maxOccurs="unbounded"/>
    </xs:choice>
  </xs:group>
  <xs:complexType name="RequestBody">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="type" type="xs:string"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="RequestHeaders">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="type" type="xs:string"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="Column">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[Optionally contained within an
``<options>`` tag set - specifies columns used in building select options from a
file stored locally (i.e. index or tool data) or a dataset in the
current history.

Any number of columns may be described, but at least one must be given the name
``value`` and it will serve as the value of this parameter in the Cheetah
template and elsewhwere (e.g. in API for instance).

If a column named ``name`` is defined, this too has special meaning and it will
be the value the tool form user sees for each option. If no ``name`` column
appears, ``value`` will serve as the name.

### Examples

The following fragment shows options from the dataset in the current history
that has been selected as the value of the parameter named ``input1``.

```xml
<options from_dataset="input1">
    <column name="name" index="0"/>
    <column name="value" index="0"/>
</options>
```

The [gff_filter_by_feature_count](https://github.com/galaxyproject/galaxy/blob/dev/tools/filters/gff/gff_filter_by_feature_count.xml)
tool makes use of this tag with files from a history, and the
[star_fusion](https://github.com/galaxyproject/tools-iuc/blob/main/tools/star_fusion/star_fusion.xml)
tool makes use of this to reference a data table.
]]></xs:documentation>
    </xs:annotation>
    <xs:attribute name="name" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en">Name given to the column with index
``index``, the names ``name`` and ``value`` have special meaning as described
above.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="index" type="xs:decimal" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en">0-based index of the column in the
target file.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="Validator">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

This tag set is contained within the ``<param>`` tag set - it applies a
validator to the containing parameter. Tool submission will fail if a
single validator fails. See the
[annotation_profiler](https://github.com/galaxyproject/tools-devteam/blob/main/tools/annotation_profiler/annotation_profiler.xml)
tool for an example of how to use this tag set.

Note that validators for parameters with ``optional="true"`` are not
executed if no value is given.

### Generic validators

- ``expression``: Check if a one line python expression given expression
evaluates to True. The expression is given is the content of the validator tag.

### Validators for ``data`` and ``data_collection`` parameters

In case of ``data_collection`` parameters and
``data`` parameters with ``multiple="true"`` these validators are executed
separately for each of the contained data sets. Note that, for ``data``
parameters a ``metadata`` validator is added automatically.

- ``metadata``: Check for missing metadata. The set of (optional) metadata
to be checked can be set using either the ``check`` or ``skip`` attribute.
Note that each data parameter has automatically a metadata validator that checks
if all non-optional metadata are set, i.e. ``<validator type="metadata/>``.
- ``unspecified_build``: Check of a build is defined.
- ``dataset_ok_validator``: Check if the data set is in state OK.
- ``dataset_metadata_equal``: Check if metadata (given by ``metadata_name``) is equal to a given string value (given by ``value``) or JSON encoded value (given by ``value_json``). ``value_json`` needs to be used for all non string types (e.g. int, float, list, dict).
- ``dataset_metadata_in_range``: Check if a numeric metadata value is within
a given range.
- ``dataset_metadata_in_data_table``: Check if a metadata value is contained in a column of a data table.
- ``dataset_metadata_not_in_data_table``: Equivalent to ``dataset_metadata_in_data_table`` with ``negate="true"``.

Deprecated data validators:

- ``dataset_metadata_in_file``: Use data tables with ``dataset_metadata_in_data_table``.
Check if a metadata value is contained in a specific column of a file in the ``tool_data_path``
(which is set in Galaxy's config).

### Validators for textual inputs (``text``, ``select``, ...)

- ``regex``: Check if a regular expression **matches** the value, i.e. appears
at the beginning of the value. To enforce a match of the complete value use
``$`` at the end of the expression. The expression is given is the content
of the validator tag. Note that for ``selects`` each option is checked
separately.
- ``length``: Check if the length of the value is within a range.
- ``empty_field``: Check if the string is not empty
- ``value_in_data_table``: Check if the value is
contained in a column of a given data table.
- ``value_not_in_data_table``: Equivalent to ``value_in_data_table`` with ``negate="true"``.

For selects (in particular with dynamically defined options) the following
validator is useful:

``no_options``: Check if options are available for a ``select`` parameter.
Useful for parameters with dynamically defined options.

### Validators for numeric inputs (``integer``, ``float``)

``in_range``: Check if the value is in a given range.

### Examples

The following demonstrates a simple validator ``unspecified_build`` ensuring
that a dbkey is present on the selected dataset. This example is taken from the
[extract_genomic_dna](https://github.com/galaxyproject/tools-iuc/blob/main/tools/extract_genomic_dna/extract_genomic_dna.xml#L42)
tool.

```xml
<param name="input" type="data" format="gff,interval" label="Fetch sequences for intervals in">
    <validator type="unspecified_build" />
</param>
```

Along the same line, the following example taken from
[samtools_mpileup](https://github.com/galaxyproject/tools-devteam/blob/main/tool_collections/samtools/samtools_mpileup/samtools_mpileup.xml)
ensures that a dbkey is present and that FASTA indices in the ``fasta_indexes``
tool data table are present.

```xml
<param format="bam" label="BAM file(s)" name="input_bam" type="data" min="1" multiple="true">
    <validator type="unspecified_build" />
    <validator type="dataset_metadata_in_data_table" metadata_name="dbkey" table_name="fasta_indexes" metadata_column="1"
               message="Sequences are not currently available for the specified build." />
</param>
```

In this older, somewhat deprecated example - a genome build of the dataset must
be stored in Galaxy clusters and the name of the genome (``dbkey``) must be one
of the values in the first column of file ``alignseq.loc`` - that could be
expressed with the validator. In general, ``dataset_metadata_in_file`` should be
considered deprecated in favor of

```xml
<validator type="dataset_metadata_in_data_table"
           metadata_name="dbkey"
           metadata_column="1"
           message="Sequences are not currently available for the specified build." />
```

A very common validator is simply ensure a Python expression is valid for a
specified value. In the following example - paths/names that downstream tools
use in filenames may not contain ``..``.

```xml
<validator type="expression" message="No two dots (..) allowed">'..' not in value</validator>
```
]]></xs:documentation>
    </xs:annotation>
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="type" type="ValidatorType" use="required">
          <xs:annotation>
            <xs:documentation xml:lang="en"><![CDATA[
Valid values are: ``expression``, ``regex``, ``in_range``, ``length``,
``metadata``, ``metadata_eq`` ``unspecified_build``, ``no_options``, ``empty_field``,
``dataset_metadata_in_data_table``, ``dataset_metadata_not_in_data_table``,
``value_in_data_table``, ``value_not_in_data_table``,
``dataset_ok_validator``, ``dataset_metadata_in_range``.
Deprecated validator: ``dataset_metadata_in_file``.
The list of supported
validators is in the ``validator_types`` dictionary in
[/lib/galaxy/tools/parameters/validation.py](https://github.com/galaxyproject/galaxy/blob/dev/lib/galaxy/tools/parameters/validation.py).
]]></xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="message" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en">
The error message displayed on the tool form if validation fails. A placeholder string ``%s`` will be repaced by the ``value``</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="negate" type="xs:boolean" default="false">
          <xs:annotation>
            <xs:documentation xml:lang="en">
Negates the result of the validator.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="check" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en">Comma-seperated list of metadata
fields to check for if type is ``metadata``. If not specified, all non-optional
metadata fields will be checked unless they appear in the list of fields
specified by the ``skip`` attribute.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="table_name" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en">Tool data table name to check against
if ``type`` is ``dataset_metadata_in_data_table``, ``dataset_metadata_not_in_data_table``, ``value_in_data_table``, or ``value_not_in_data_table``. See the documentation for
[tool data tables](https://galaxyproject.org/admin/tools/data-tables)
and [data managers](https://galaxyproject.org/admin/tools/data-managers/) for
more information.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="filename" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en">Deprecated: use ``dataset_metadata_in_data_table``. Tool data filename to check against
if ``type`` is ``dataset_metadata_in_file``. File should be present Galaxy's
``tool-data`` directory.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="metadata_name" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en">Target metadata attribute name for
``dataset_metadata_in_data_table``, ``dataset_metadata_not_in_data_table``, ``dataset_metadata_in_file`` and ``dataset_metadata_in_range`` options.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="metadata_column" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en">Target column for metadata attribute
in ``dataset_metadata_in_data_table``, ``dataset_metadata_not_in_data_table``, ``value_in_data_table``, ``value_not_in_data_table``, and ``dataset_metadata_in_file`` options.
This can be an integer index to the column or a column name.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="min" type="xs:decimal">
          <xs:annotation>
            <xs:documentation xml:lang="en">When the ``type`` attribute value is
``in_range``, ``length``, or ``dataset_metadata_in_range`` - this is the minimum number allowed.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="max" type="xs:decimal">
          <xs:annotation>
            <xs:documentation xml:lang="en">When the ``type`` attribute value is
``in_range``, ``length``, or ``dataset_metadata_in_range`` - this is the maximum number allowed.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="exclude_min" type="xs:boolean" default="false">
          <xs:annotation>
            <xs:documentation xml:lang="en">When the ``type`` attribute value is
``in_range``, ``length``, or ``dataset_metadata_in_range`` - this boolean indicates if the ``min`` value is allowed.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="exclude_max" type="xs:boolean" default="false">
          <xs:annotation>
            <xs:documentation xml:lang="en">When the ``type`` attribute value is
``in_range``, ``length``, or ``dataset_metadata_in_range`` - this boolean indicates if the ``max`` value is allowed.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="split" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en">If ``type`` is ``dataset_metadata_in_file``,
this attribute is the column separator to use for values in the specified file.
This default is ``\t`` and due to a bug in older versions of Galaxy, should
not be modified.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="skip" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en">Comma-seperated list of metadata
fields to skip if type is ``metadata``. If not specified, all non-optional
metadata fields will be checked unless ``check`` attribute is specified.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="value" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en">Value to check the metadata against. Only
applicable to ``dataset_metadata_equal``. Mutually exclusive with ``value_json``.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="value_json" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en">JSON encoded value to check the metadata against. Only
applicable to ``dataset_metadata_equal``. Mutually exclusive with ``value``.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="line_startswith" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en">Deprecated. Used to indicate lines in the file
being used for validation start with a this attribute value.
For use with validator ``dataset_metadata_in_file``</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="substitute_value_in_message" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en">Deprecated. This is now always done.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="Sanitizer">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

See
[/tools/filters/grep.xml](https://github.com/galaxyproject/galaxy/blob/dev/tools/filters/grep.xml)
for a typical example of how to use this tag set. This tag set is used to
replace the basic parameter sanitization with custom directives. This tag set is
contained within the ``<param>`` tag set - it contains a set of ``<valid>`` and
``<mapping>`` tags.

### Character presets

The following presets can be used when specifying the valid characters: the
[constants](https://docs.python.org/3/library/string.html#string-constants) from the ``string`` Python3 module,
plus ``default`` (equal to ``string.ascii_letters + string.digits + " -=_.()/+*^,:?!"``)
and ``none`` (empty set).
The ``string.letters``, ``string.lowercase`` and ``string.uppercase`` Python2
constants are accepted for backward compatibility, but are aliased to the
corresponding not locale-dependent constant (i.e. ``string.ascii_letters``,
``string.ascii_lowercase`` and ``string.ascii_uppercase`` respectively).

### Examples

This example specifies to use the empty string as the invalid character (instead
of the default ``X``, so invalid characters are effectively dropped instead of
replaced with ``X``) and indicates that the only valid characters for this input
are ASCII letters, digits, and ``_``.

```xml
<param name="mystring" type="text" label="Say something interesting">
    <sanitizer invalid_char="">
        <valid initial="string.ascii_letters,string.digits">
            <add value="_" />
        </valid>
    </sanitizer>
</param>
```

This example allows many more valid characters and specifies that ``&`` will just
be dropped from the input.

```xml
<sanitizer>
    <valid initial="string.printable">
        <remove value="&amp;"/>
    </valid>
    <mapping initial="none">
        <add source="&amp;" target=""/>
    </mapping>
</sanitizer>
```
]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:group ref="SanitizerElement" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="sanitize" type="PermissiveBoolean" default="true">
      <xs:annotation>
        <xs:documentation xml:lang="en">This boolean parameter determines if the
input is sanitized at all (the default is ``true``).</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="invalid_char" type="xs:string" default="X">
      <xs:annotation>
        <xs:documentation xml:lang="en">The attribute specifies the character
used as a replacement for invalid characters (the default is ``X``).</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:group name="SanitizerElement">
    <xs:choice>
      <xs:element name="valid" type="SanitizerValid"/>
      <xs:element name="mapping" type="SanitizerMapping"/>
    </xs:choice>
  </xs:group>
  <xs:complexType name="SanitizerValid">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[Contained within the
``<sanitizer>`` tag set, these are used to specify a list of allowed characters.
Contains ``<add>`` and ``<remove>`` tags.]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:group ref="SanitizerValidElement" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="initial" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">This describes the initial characters to
allow as valid, specified as a character preset (as defined above). The default
is the ``default`` preset.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="SanitizerValidAdd">
    <xs:annotation>
      <xs:documentation xml:lang="en">This directive is used to add individual
characters or preset lists of characters. Character must not be allowed as a
valid input for the mapping to occur.</xs:documentation>
    </xs:annotation>
    <xs:attribute name="preset" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Add the characters contained in the specified character preset (as defined above) to the list of valid characters. The default
is the ``none`` preset.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="value" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Add a character to the list of valid characters.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="SanitizerValidRemove">
    <xs:annotation>
      <xs:documentation xml:lang="en">This directive is used to remove
individual characters or preset lists of characters.
Character must not be allowed as a valid input for the mapping to occur.</xs:documentation>
    </xs:annotation>
    <xs:attribute name="preset" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Remove the characters contained in the specified character preset (as defined above) from the list of valid characters. The default
is the ``none`` preset.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="value" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">A character to remove from the list of valid characters.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:group name="SanitizerValidElement">
    <xs:choice>
      <xs:element name="add" type="SanitizerValidAdd"/>
      <xs:element name="remove" type="SanitizerValidRemove"/>
    </xs:choice>
  </xs:group>
  <xs:complexType name="SanitizerMapping">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[Contained within the ``<sanitizer>`` tag set. Used to specify a mapping of disallowed character to replacement string. Contains ``<add>`` and ``<remove>`` tags.]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:group ref="SanitizerMappingElement" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="initial" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Initial character mapping (default is ``galaxy.util.mapped_chars``)</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="SanitizerMappingAdd">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[Use to add character mapping during sanitization. Character must not be allowed as a valid input for the mapping to occur.]]></xs:documentation>
    </xs:annotation>
    <xs:attribute name="source" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Replace all occurrences of this character with the string of ``target``.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="target" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Replace all occurrences of ``source`` with this string</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="SanitizerMappingRemove">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[Use to remove character mapping during sanitization.]]></xs:documentation>
    </xs:annotation>
    <xs:attribute name="source" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Character to remove from mapping.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:group name="SanitizerMappingElement">
    <xs:choice>
      <xs:element name="add" type="SanitizerMappingAdd" minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="remove" type="SanitizerMappingRemove" minOccurs="0" maxOccurs="unbounded"/>
    </xs:choice>
  </xs:group>
  <xs:complexType name="Filter">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[Optionally contained within an
``<options>`` tag set - modify (e.g. remove, add, sort, ...) the list of values obtained from a locally stored file (e.g.
a tool data table) or a dataset in the current history.

Currently the following filters are defined:

* ``static_value`` filter options for which the entry in a given ``column`` of the referenced file based on equality to the ``value`` attribute of the filter.
* ``regexp`` similar to the ``static_value`` filter, but checks if the regular expression given by ``value`` matches the entry.
* ``param_value`` filter options for which the entry in a given ``column`` of the referenced file based on properties of another input parameter specified by ``ref``. This property is by default the value of the parameter, but also the values of another attribute (``ref_attribute``) of the parameter can be used, e.g. the extension of a data input.
* ``data_meta`` populate or filter options based on the metadata of another input parameter specified by ``ref``. If a ``column`` is given options are filtered for which the entry in this column ``column`` is equal to metadata of the input parameter specified by ``ref``.
If no ``column`` is given the metadata value of the referenced input is added to the options list (in this case the corresponding ``options`` tag must not have the ``from_data_table`` or ``from_dataset`` attributes).
In both cases the desired metadata is selected by ``key``.
* ``data_table`` remove values according to the entries of a data table. Remove options where the value in ``column`` appears in the data table ``table_name`` in column ``table_column``. Setting ``keep`` will to ``true`` will keep only entries also appearing in the data table.

The ``static_value``, ``regexp``, and ``data_table`` filters can be inverted by setting ``keep`` to true.

* ``add_value``: add an option with a given ``name`` and ``value`` to the options. By default, the new option is appended, with ``index`` the insertion position can be specified.
* ``remove_value``: remove a value from the options. Either specified explicitly with ``value``, the value of another input specified with ``ref``, or the metadata ``key`` of another input ``meta_ref``.
* ``unique_value``: remove options that have duplicate entries in the given ``column``.
* ``sort_by``: sort options by the entries of a given ``column``. If ``reverse_sort_order`` is set to ``true``, reverse sort order from ascending to descending.
* ``multiple_splitter``: split the entries of the specified ``column``(s) in the referenced file using a ``separator``. Thereby the number of columns is increased.
* ``attribute_value_splitter``: split the attribute-value pairs within the specified ``column`` in the referenced file using ``pair_separator`` and ``name_val_separator``. Thereby a new column is introduced before ``column`` containing a list of all attribute names.


### Examples

The following example from Mothur's
[remove.groups.xml](https://github.com/galaxyproject/tools-iuc/blob/main/tools/mothur/remove.groups.xml)
tool demonstrates filtering a select list based on the metadata of an input to
to the tool.

```xml
<param name="group_in" type="data" format="mothur.groups,mothur.count_table" label="group or count table - Groups"/>
<param name="groups" type="select" label="groups - Pick groups to remove" multiple="true" optional="false">
    <options>
        <filter type="data_meta" ref="group_in" key="groups"/>
    </options>
</param>
```

This more advanced example, taken from Mothur's
[remove.lineage.xml](https://github.com/galaxyproject/tools-iuc/blob/main/tools/mothur/remove.lineage.xml)
tool demonstrates using filters to sort a list and remove duplicate entries.

```xml
<param name="taxonomy" type="data" format="mothur.cons.taxonomy" label="constaxonomy - Constaxonomy file. Provide either a constaxonomy file or a taxonomy file" help="please make sure your file has no quotation marks in it"/>
<param name="taxons" type="select" optional="true" multiple="true" label="Browse Taxons from Taxonomy">
    <options from_dataset="taxonomy">
        <column name="name" index="2"/>
        <column name="value" index="2"/>
        <filter type="unique_value" name="unique_taxon" column="2"/>
        <filter type="sort_by" name="sorted_taxon" column="2"/>
    </options>
    <sanitizer>
        <valid initial="default">
            <add preset="string.printable"/>
            <add value=";"/>
            <remove value="&quot;"/>
            <remove value="&apos;"/>
        </valid>
    </sanitizer>
</param>
```

This example taken from the
[hisat2](https://github.com/galaxyproject/tools-iuc/blob/main/tools/hisat2/hisat2.xml)
tool demonstrates filtering values from a tool data table.

```xml
<param help="If your genome of interest is not listed, contact the Galaxy team" label="Select a reference genome" name="index" type="select">
    <options from_data_table="hisat2_indexes">
        <filter column="2" type="sort_by" />
    </options>
    <validator message="No genomes are available for the selected input dataset" type="no_options" />
</param>
```

The
[gemini_load.xml](https://github.com/galaxyproject/tools-iuc/blob/main/tools/gemini/gemini_load.xml)
tool demonstrates adding values to an option list using ``filter``s.

```xml
<param name="infile" type="data" format="vcf" label="VCF file to be loaded in the GEMINI database" help="Only build 37 (aka hg19) of the human genome is supported.">
    <options>
        <filter type="add_value" value="hg19" />
        <filter type="add_value" value="Homo_sapiens_nuHg19_mtrCRS" />
        <filter type="add_value" value="hg_g1k_v37" />
    </options>
</param>
```

While this fragment from [maf_to_interval.xml](https://github.com/galaxyproject/galaxy/blob/dev/tools/maf/maf_to_interval.xml) demonstrates removing items.

```xml
<param name="species" type="select" label="Select additional species"
       display="checkboxes" multiple="true"
       help="The species matching the dbkey of the alignment is always included.
       A separate history item will be created for each species.">
    <options>
        <filter type="data_meta" ref="input1" key="species" />
        <filter type="remove_value" meta_ref="input1" key="dbkey" />
    </options>
</param>
```

This example taken from
[snpSift_dbnsfp.xml](https://github.com/galaxyproject/tools-iuc/blob/main/tool_collections/snpsift/snpsift_dbnsfp/snpSift_dbnsfp.xml)
demonstrates splitting up strings into multiple values.

```xml
<param name="annotations" type="select" multiple="true" display="checkboxes" label="Annotate with">
    <options from_data_table="snpsift_dbnsfps">
        <column name="name" index="4"/>
        <column name="value" index="4"/>
        <filter type="param_value" ref="dbnsfp" column="3" />
        <filter type="multiple_splitter" column="4" separator=","/>
    </options>
</param>
```

This example demonstrates compiling a list of available attributes by parsing a GFF containing a column of multiple attribute-value pairs formatted in the input as ``gene_id=ABC;transcript_id=abc;transcript_biotype=mRNA``

```xml
<param name="available_attributes" type="select" label="List of all attributes mentioned in a GFF">
    <options from_data_table="a_gff_as_table">
        <column name="name" index="8"/>
        <column name="value" index="8"/>
        <filter type="attribute_value_splitter" column="8" pair_separator=";" name_val_separator="="/>
    </options>
</param>
```


]]></xs:documentation>
    </xs:annotation>
    <xs:attribute name="type" type="FilterType" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
Currently the filters in the ``filter_types`` dictionary in the module
[/lib/galaxy/tools/parameters/dynamic_options.py](https://github.com/galaxyproject/galaxy/blob/dev/lib/galaxy/tools/parameters/dynamic_options.py) are defined.
        ]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="column" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Column targeted by this filter given as 0-based column index or a column name. Invalid if ``type`` is ``add_value`` or ``remove_value``.
</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="name" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Name displayed for value to add (only
used with ``type`` of ``add_value``).</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="ref" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">The attribute name of the reference file
(tool data) or input dataset. Only used when ``type`` is
``data_meta`` (required), ``param_value`` (required), or ``remove_value``
(optional).</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="key" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">When ``type`` is ``data_meta``, ``param_value``,
or ``remove_value`` - this is the name of the metadata key to filter by.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="multiple" type="PermissiveBoolean" default="false">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[For types ``data_meta`` and
``remove_value``, whether option values are multiple. Columns will be split by
separator. Defaults to ``false``.]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="separator" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[When ``type`` is ``data_meta``,
``multiple_splitter``, or ``remove_value`` - this is used to split one value
into multiple parts. When ``type`` is ``data_meta`` or ``remove_value`` this is
only used if ``multiple`` is set to ``true``.]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="keep" type="PermissiveBoolean" default="true">
      <xs:annotation>
        <xs:documentation xml:lang="en">If ``true``, keep columns matching the
value, if ``false`` discard columns matching the value. Used when ``type`` is
either ``static_value``, ``regexp``, ``param_value`` or ``data_table``. Default: true.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="value" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Target value of the operations - has
slightly different meanings depending on ``type``. For instance when ``type`` is
``add_value`` it is the value to add to the list and when ``type`` is
``static_value`` or ``regexp`` it is the value compared against.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="ref_attribute" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Only used when ``type`` is
``param_value``. Period (``.``) separated attribute chain of input (``ref``)
attributes to use as value for filter.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="index" type="xs:integer">
      <xs:annotation>
        <xs:documentation xml:lang="en">Used when ``type`` is ``add_value``, it
is the index into the list to add the option to. If not set, the option will be
added to the end of the list.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="meta_ref" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Only used when ``type`` is
``remove_value``. Dataset to look for the value of metadata ``key`` to remove
from the list.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="reverse_sort_order" type="xs:boolean" default="false">
      <xs:annotation>
        <xs:documentation xml:lang="en">Used when ``type`` is ``sort_by``, if set to
        ``true`` it will reverse the sort order from ascending to descending. Default
        is ``false``.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="pair_separator" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Only used if ``type`` is ``attribute_value_splitter``. This is used to separate attribute-value pairs from other pairs, i.e. ``;`` if the target content is ``A=V; B=W; C=Y`` . Default is ``,``.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="name_val_separator" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Only used if ``type`` is ``attribute_value_splitter``. This is used to separate attributes and values from each other within an attribute-value pair, i.e. ``=`` if the target content is ``A=V; B=W; C=Y``. Defaults to whitespace.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="table_name" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Only used when ``type`` is
``data_table``. The name of the data table to use.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="data_table_column" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Only used when ``type`` is
``data_table``. The column of the data table to use (0 based index or column name).</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="Outputs">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[
Container tag set for the ``<data>`` and ``<collection>`` tag sets.
The files and collections created by tools as a result of their execution are
named by Galaxy. You specify the number and type of your output files using the
contained ``<data>`` and ``<collection>`` tags. These may be passed to your tool
executable through using line variables just like the parameters described in
the ``<inputs>`` documentation.
]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:group ref="OutputsElement" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="provided_metadata_style" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
Style used for tool provided metadata file (i.e.
[galaxy.json](https://planemo.readthedocs.io/en/latest/writing_advanced.html#tool-provided-metadata))
- this can be either "legacy" or "default". The default of tools with a profile
of 17.09 or newer are "default", and "legacy" for older and tools and tools
without a specified profile. A discussion of the differences between the styles
can be found [here](https://github.com/galaxyproject/galaxy/pull/4437).
]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="provided_metadata_file" type="xs:string" default="galaxy.json">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
Path relative to tool's working directory to load tool provided metadata from.
This metadata can describe dynamic datasets to load, dynamic collection
contents, as well as simple metadata (e.g. name, dbkey, etc...) and
datatype-specific metadata for declared outputs. More information can be found
[here](https://planemo.readthedocs.io/en/latest/writing_advanced.html#tool-provided-metadata).
The default is ``galaxy.json``.
]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:group name="OutputsElement">
    <xs:choice>
      <xs:element name="output" type="Output"/>
      <xs:element name="data" type="OutputData"/>
      <xs:element name="collection" type="OutputCollection"/>
    </xs:choice>
  </xs:group>
  <xs:group name="OutputDataElement">
    <xs:choice>
      <xs:element name="change_format" type="ChangeFormat"/>
      <xs:element name="filter" type="OutputFilter"/>
      <xs:element name="discover_datasets" type="OutputDiscoverDatasets"/>
      <xs:element name="actions" type="Actions"/>
    </xs:choice>
  </xs:group>
  <xs:attributeGroup name="OutputCommon">
    <xs:attribute name="format" type="Format">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
The short name for the output datatype. The valid values for format can be found in
[/config/datatypes_conf.xml.sample](https://github.com/galaxyproject/galaxy/blob/dev/config/datatypes_conf.xml.sample)
(e.g. ``format="pdf"`` or ``format="fastqsanger"``). For collections this is the default
format for all included elements. Note that the format specified here is ignored for
discovered data sets on Galaxy versions prior to 24.0 and should be specified using the ``<discovered_data>`` tag set.
        ]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="format_source" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">This sets the data type of the output dataset(s) to be the same format as that of the specified tool input.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="label" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[

This will be the name of the history item for the output data set. The string
can include structure like ``${<some param name>.<some attribute>}``, as
discussed for command line parameters in the ``<command>`` tag set section
above. The default label is ``${tool.name} on ${on_string}``.

]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="name" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[Name for this output. This
``name`` is used as the Cheetah variable containing the Galaxy assigned output
path in ``command`` and ``configfile`` elements. The name should not contain
pipes or periods (e.g. ``.``).]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:attributeGroup>
  <xs:attributeGroup name="OutputDataAttributes">
    <xs:attribute name="auto_format" type="PermissiveBoolean">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[

If ``true``, this output will sniffed and its format determined automatically by Galaxy.

]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="default_identifier_source" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Sets the source of element identifier to the specified input.
This only applies to collections that are mapped over a non-collection input and that have equivalent structures. If this references input elements in conditionals, this value should be qualified (e.g. ``cond|input`` instead of ``input`` if ``input`` is in a conditional with ``name="cond"``).</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="metadata_source" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">This copies the metadata information
from the tool's input dataset to serve as default for information that cannot be detected from the output.
One prominent use case is interval data with a non-standard column order that cannot be deduced from a header line, but which is known to be identical in the input and output datasets.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="from_work_dir" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Relative path to a file produced by the
tool in its working directory. Output's contents are set to this file's
contents. The behaviour when this file does not exist in the working directory is undefined; the resulting dataset could be empty or the tool execution could fail.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="hidden" type="xs:boolean" default="false">
      <xs:annotation>
        <xs:documentation xml:lang="en">Boolean indicating whether to hide
dataset in the history view. (Default is ``false``.)</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:attributeGroup>
  <xs:attributeGroup name="OutputCollectionAttributes">
    <xs:attribute name="structured_like" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">This is the name of input collection or
dataset to derive "structure" of the output from (output element count and
identifiers). For instance, if the referenced input has three ordered items with
identifiers ``sample1``, ``sample2``,  and ``sample3``. If this references input
elements in conditionals, this value should be qualified (e.g. ``cond|input`` instead
of ``input`` if ``input`` is in a conditional with ``name="cond"``).</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="inherit_format" type="xs:boolean">
      <xs:annotation>
        <xs:documentation xml:lang="en">If ``structured_like`` is set, inherit
format of outputs from format of corresponding input.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:attributeGroup>
  <xs:complexType name="OutputData">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

This tag set is contained within the ``<outputs>`` tag set, and it defines the
output data description for the files resulting from the tool's execution. The
value of the attribute ``label`` can be acquired from input parameters or metadata
in the same way that the command line parameters are (discussed in the
``<command>`` tag set section above).

### Examples

The following will create a variable called ``$out_file1`` with data type
``pdf``.

```xml
<outputs>
    <data format="pdf" name="out_file1" />
</outputs>
```

The valid values for format can be found in
[/config/datatypes_conf.xml.sample](https://github.com/galaxyproject/galaxy/blob/dev/config/datatypes_conf.xml.sample).

The following will create a dataset in the history panel whose data type is the
same as that of the input dataset selected (and named ``input1``) for the tool.

```xml
<outputs>
    <data format_source="input1" name="out_file1" metadata_source="input1"/>
</outputs>
```

The following will create datasets in the history panel, setting the output data
type to be the same as that of an input dataset named by the ``format_source``
attribute. Note that a conditional name is not included, so 2 separate
conditional blocks should not contain parameters with the same name.

```xml
<inputs>
    <!-- fasta may be an aligned fasta that subclasses Fasta -->
    <param name="fasta" type="data" format="fasta" label="fasta - Sequences"/>
    <conditional name="qual">
        <param name="add" type="select" label="Trim based on a quality file?" help="">
            <option value="no">no</option>
            <option value="yes">yes</option>
        </param>
        <when value="no"/>
        <when value="yes">
            <!-- qual454, qualsolid, qualillumina -->
            <param name="qfile" type="data" format="qual" label="qfile - a quality file"/>
        </when>
    </conditional>
</inputs>
<outputs>
    <data format_source="fasta" name="trim_fasta"
          label="${tool.name} on ${on_string}: trim.fasta"/>
    <data format_source="qfile" name="trim_qual"
          label="${tool.name} on ${on_string}: trim.qual">
        <filter>qual['add'] == 'yes'</filter>
    </data>
</outputs>
```

Assume that the tool includes an input parameter named ``database`` which is a
select list (as shown below). Also assume that the user selects the first option
in the ``$database`` select list. Then the following will ensure that the tool
produces a tabular data set whose associated history item has the label ``Blat
on Human (hg18)``.

```xml
<inputs>
    <param format="tabular" name="input" type="data" label="Input stuff"/>
    <param type="select" name="database" label="Database">
        <option value="hg18">Human (hg18)</option>
        <option value="dm3">Fly (dm3)</option>
    </param>
</inputs>
<outputs>
    <data format="input" name="output" label="Blat on ${database.value_label}" />
</outputs>
```

]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:group ref="OutputDataElement" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <!-- TODO: add a unique constraint for action. -->
    <xs:attributeGroup ref="OutputCommon"/>
    <xs:attributeGroup ref="OutputDataAttributes"/>
  </xs:complexType>
  <!-- Allowed tags included in collection-data -->
  <xs:group name="OutputCollectionDataElement">
    <xs:choice>
      <xs:element name="actions" type="Actions"/>
      <xs:element name="change_format" type="ChangeFormat"/>
    </xs:choice>
  </xs:group>
  <!-- Allowed tags included in collection -->
  <xs:group name="OutputCollectionElement">
    <xs:choice>
      <xs:element name="data" type="OutputCollectionData"/>
      <xs:element name="discover_datasets" type="OutputCollectionDiscoverDatasets"/>
      <xs:element name="filter" type="OutputFilter"/>
    </xs:choice>
  </xs:group>
  <xs:complexType name="OutputCollectionData">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

This tag set is contained within the ``<collection>`` tag set, and can be used to
define the elements of a collection statically. See also [Planemo's documentation](https://planemo.readthedocs.io/en/latest/writing_advanced.html#static-element-count).
]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:group ref="OutputCollectionDataElement" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attributeGroup ref="OutputCommon"/>
    <xs:attributeGroup ref="OutputDataAttributes"/>
  </xs:complexType>
  <xs:complexType name="OutputCollection">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

This tag set is contained within the ``<outputs>`` tag set, and it defines the
output dataset collection description resulting from the tool's execution. The
value of the attribute ``label`` can be acquired from input parameters or
metadata in the same way that the command line parameters are (discussed in the
[command](#tool-command) directive).

Creating collections in tools is covered in-depth in
[Planemo's documentation](https://planemo.readthedocs.io/en/latest/writing_advanced.html#creating-collections).

]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:group ref="OutputCollectionElement" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attributeGroup ref="OutputCommon"/>
    <xs:attributeGroup ref="OutputCollectionAttributes"/>
    <xs:attribute name="type" type="CollectionType">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
Collection type for output. Simple collection types are either ``list`` or
``paired``, nested collections are specified as colon separated list of simple
collection types (the most common types are ``list``, ``paired``,
``list:paired``, or ``list:list``).
        ]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="type_source" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">This is the name of input collection to
derive collection's type (e.g. ``collection_type``) from.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="Output">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

This tag describes an output to the tool.
]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:group ref="OutputDataElement" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attributeGroup ref="OutputCommon"/>
    <xs:attributeGroup ref="OutputCollectionAttributes"/>
    <xs:attribute name="type" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Output type. This could be older more established Galaxy types (e.g. data and collection) - in which case the semantics of this largely reflect the corresponding ``data`` and ``collection`` tags. This could also be newer non-data types such as ``integer`` or ``boolean``.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="from" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">In expression tools, use this to specify a dictionary value to populate this output from. The semantics may change for other expression types in the future.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="collection_type" type="CollectionType">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
Collection type for output. Simple collection types are either ``list`` or
``paired``, nested collections are specified as colon separated list of simple
collection types (the most common types are ``list``, ``paired``,
``list:paired``, or ``list:list``).
        ]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="collection_type_source" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">This is the name of input collection to
derive collection's type (e.g. ``collection_type``) from.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="OutputFilter">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[
The ``<data>`` tag can contain a ``<filter>`` tag which includes a Python code
block to be executed to test whether to include this output in the outputs the
tool ultimately creates. If the code, when executed, returns ``True``,
the output dataset is retained. In these code blocks the tool parameters appear
as Python variables and are thus referred to without the $ used for the Cheetah
template (used in the ``<command>`` tag). Variables that are part of
conditionals are accessed using a dictionary named after the conditional. Boolean
parameters appear as booleans, not the value of their ``truevalue`` and
``falsevalue`` attributes. In the example below, ``options["selection_mode"]`` would
appear as ``$options.selection_mode`` in Cheetah. Similarly ``options["vcf_output"]``
would appear as ``$options.vcf_output`` having the values ``'--vcf'`` when true and
``''`` when false in Cheetah.
Note that also parameters in sections are accessed via a dictionary.

### Example

```xml
    <inputs>
      <param type="data" format="fasta" name="reference_genome" label="Reference genome" />
      <param type="data" format="bam" name="input_bam" label="Aligned reads" />
      <conditional name="options">
        <param label="Use advanced options" name="selection_mode" type="select">
          <option selected="true" value="defaults">Use default options</option>
          <option value="advanced">Use advanced options</option>
        </param>
        <when value="defaults" />
        <when value="advanced">
          <param name="vcf_output" type="boolean" checked="false" label="VCF output"
            truevalue="--vcf" falsevalue="" />
        </when>
      </conditional>
    </inputs>
    <outputs>
      <data format="txt" label="Alignment report on ${on_string}" name="output_txt" />
      <data format="vcf" label="Variant summary on ${on_string}" name="output_vcf">
          <filter>options['selection_mode'] == 'advanced' and options['vcf_output']</filter>
      </data>
    </outputs>
```

Note that variables that correspond to optional select parameters are `None` if nothing is selected.
Therefore a filter for such a variable looks like the following example.

### Example

```xml
    <inputs>
       <param name="output_type" type="select" optional="true">
            <option value="save_phase">Phase Movie</option>
            <option value="save_period">Period Movie</option>
        </param>
    </inputs>

    <outputs>
        <data name="phase_out" format="tiff">
            <filter>output_type and "save_phase" in output_type</filter>
        </data>
        <data name="period_out" format="tiff" label="${movie.name[:-4]}_period">
            <filter>output_type and "save_period" in output_type</filter>
        </data>
    </outputs>
```

]]></xs:documentation>
    </xs:annotation>
    <xs:simpleContent>
      <xs:extension base="xs:string">
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:attributeGroup name="OutputDiscoverDatasetsCommon">
    <xs:attribute name="from_provided_metadata" type="xs:boolean" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en">Indicate that dataset filenames should simply be read from the provided metadata file (e.g. galaxy.json). If this is set - pattern and sort must not be set.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="pattern" type="xs:string" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en">Regular expression used to find filenames and parse dynamic properties.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="directory" type="xs:string" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en">Directory (relative to working directory) to search for files.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="recurse" type="xs:boolean" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en">Indicates that the specified directory should be searched recursively for matching files.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="match_relative_path" type="xs:boolean" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en">Indicates that the entire path of the discovered dataset relative to the specified directory should be available for matching patterns.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="format" type="Format" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en">Format (or datatype) of discovered datasets (an alias with ``ext``).</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="ext" type="Format" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en">Format (or datatype) of discovered datasets (an alias with ``format``).</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="sort_by" type="xs:string" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
        A string `[reverse_][SORT_COMP_]SORTBY` describing the desired sort order of the collection elements.
        `SORTBY` can be `filename`, `name`, `designation`, `dbkey` and the optional `SORT_COMP` can be either
        `lexical` or `numeric`. Default is lexical sorting by filename.
        Note that lexical sorting is case sensitive, i.e. upper case characters come before lower case characters (e.g. "Apple" < "Banana" < "apple" < "banana").
        ]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="visible" type="xs:boolean" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en">Indication if this dataset is visible in output history. This defaults to ``false``, but probably shouldn't - be sure to set to ``true`` if that is your intention.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:attributeGroup>
  <xs:complexType name="OutputDiscoverDatasets">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

Describe datasets to dynamically collect after the job complete.

There are many simple tools with examples of this element distributed with
Galaxy, including:

* [multi_output.xml](https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/multi_output.xml)
* [multi_output_assign_primary.xml](https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/multi_output_assign_primary.xml)
* [multi_output_configured.xml](https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/multi_output_configured.xml)

More information can be found on Planemo's documentation for
[multiple output files](https://planemo.readthedocs.io/en/latest/writing_advanced.html#multiple-output-files).
]]></xs:documentation>
    </xs:annotation>
    <xs:attributeGroup ref="OutputDiscoverDatasetsCommon"/>
    <xs:attribute name="assign_primary_output" type="xs:boolean" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en">Replace the primary dataset described by the parameter ``data`` parameter with the first output discovered.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="OutputCollectionDiscoverDatasets">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

This tag allows one to describe the datasets contained within an output
collection dynamically, such that the outputs are "discovered" based on regular
expressions after the job is complete.

There are many simple tools with examples of this element distributed with
Galaxy, including:

* [collection_split_on_column.xml](https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/collection_split_on_column.xml)
* [collection_creates_dynamic_list_of_pairs.xml](https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/collection_creates_dynamic_list_of_pairs.xml)
* [collection_creates_dynamic_nested.xml](https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/collection_creates_dynamic_nested.xml)

]]></xs:documentation>
    </xs:annotation>
    <xs:attributeGroup ref="OutputDiscoverDatasetsCommon"/>
  </xs:complexType>
  <xs:complexType name="Actions">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[
The ``actions`` directive allows tools to dynamically take actions related to an
``output`` either unconditionally or conditionally based on inputs. These
actions currently include setting metadata values and the output's data format.

The examples below will demonstrate that the ``actions`` tag contains child
``conditional`` tags. The these conditionals are met, additional ``action``
directives below the conditional are apply to the ``data`` output.

### Metadata

The ``<actions>`` in the Bowtie 2 wrapper is used in lieu of the deprecated
``<code>`` tag to set the ``dbkey`` of the output dataset. In
[bowtie2_wrapper.xml](https://github.com/galaxyproject/tools-devteam/blob/main/tools/bowtie2/bowtie2_wrapper.xml)
(see below), according to the first action block, if the
``reference_genome.source`` is ``indexed`` (not ``history``), then it will assign
the ``dbkey`` of the output file to be the same as that of the reference file. It
does this by looking at through the data table and finding the entry that has the
value that's been selected in the index dropdown box as column 1 of the loc file
entry and using the dbkey, in column 0 (ignoring comment lines (starting with #)
along the way).

If ``reference_genome.source`` is ``history``, it pulls the ``dbkey`` from the
supplied file.

```xml
<data format="bam" name="output" label="${tool.name} on ${on_string}: aligned reads (sorted BAM)">
  <filter>analysis_type['analysis_type_selector'] == "simple" or analysis_type['sam_opt'] is False</filter>
  <actions>
    <conditional name="reference_genome.source">
      <when value="indexed">
        <action type="metadata" name="dbkey">
          <option type="from_data_table" name="bowtie2_indexes" column="1" offset="0">
            <filter type="param_value" column="0" value="#" compare="startswith" keep="false"/>
            <filter type="param_value" ref="reference_genome.index" column="0"/>
          </option>
        </action>
      </when>
      <when value="history">
        <action type="metadata" name="dbkey">
          <option type="from_param" name="reference_genome.own_file" param_attribute="dbkey" />
        </action>
      </when>
    </conditional>
  </actions>
</data>
```

### Format

The Bowtie 2 example also demonstrates conditionally setting an output format
based on inputs, as shown below:

```xml
<data format="fastqsanger" name="output_unaligned_reads_r" label="${tool.name} on ${on_string}: unaligned reads (R)">
    <filter>(library['type'] == "paired" or library['type'] == "paired_collection") and library['unaligned_file'] is True</filter>
    <actions>
        <conditional name="library.type">
            <when value="paired">
                <action type="format">
                    <option type="from_param" name="library.input_2" param_attribute="ext" />
                </action>
            </when>
            <when value="paired_collection">
                <action type="format">
                    <option type="from_param" name="library.input_1" param_attribute="reverse.ext" />
                </action>
            </when>
        </conditional>
    </actions>
</data>
```

Note that the value given in ``when`` tags needs to be the python string representation
of the value of the referred parameter, e.g. ``True`` or ``False`` if the referred
parameter is a boolean.


### Unconditional Actions and Column Names

For a static file that contains a fixed number of columns, it is straight forward:

```xml
<outputs>
    <data format="tabular" name="table">
        <actions>
            <action name="column_names" type="metadata" default="Firstname,Lastname,Age" />
        </actions>
    </data>
</outputs>
```

It may also be necessary to use column names based on a variable from another
input file. This is implemented in the
[htseq-count](https://github.com/galaxyproject/tools-iuc/blob/main/tools/htseq_count/htseq-count.xml)
and
[featureCounts](https://github.com/galaxyproject/tools-iuc/blob/main/tools/featurecounts/featurecounts.xml)
wrappers:

```xml
<inputs>
    <data name="input_file" type="data" multiple="false">
</inputs>
<outputs>
    <data format="tabular" name="output_short">
        <actions>
            <action name="column_names" type="metadata" default="Geneid,${input_file.name}" />
        </actions>
    </data>
</outputs>
```

Or in case of multiple files:

```xml
<inputs>
    <data name="input_files" type="data" multiple="true">
</inputs>
<outputs>
    <data format="tabular" name="output_short">
        <actions>
            <action name="column_names" type="metadata" default="Geneid,${','.join([a.name for a in $input_files])}" />
        </actions>
    </data>
</outputs>
```

### Unconditional Actions - An Older Example

The first approach above to setting ``dbkey`` based on tool data tables is
prefered, but an older example using so called "loc files" directly is found
below.

In addition to demonstrating this lower-level direct access of .loc files, it
demonstrates an unconditional action. The second block would not be needed for
most cases - it was required in this tool to handle the specific case of a small
reference file used for functional testing. It says that if the dbkey has been
set to ``equCab2chrM`` (which is what the ``<filter type="metadata_value"...
column="1" />`` tag does), then it should be changed to ``equCab2`` (which is the
``<option type="from_param" ... column="0" ...>`` tag does).

```xml
<actions>
   <conditional name="refGenomeSource.genomeSource">
      <when value="indexed">
           <action type="metadata" name="dbkey">
            <option type="from_file" name="bowtie_indices.loc" column="0" offset="0">
               <filter type="param_value" column="0" value="#" compare="startswith" keep="false"/>
               <filter type="param_value" ref="refGenomeSource.index" column="1"/>
            </option>
         </action>
       </when>
    </conditional>
    <!-- Special casing equCab2chrM to equCab2 -->
    <action type="metadata" name="dbkey">
        <option type="from_param" name="refGenomeSource.genomeSource" column="0" offset="0">
            <filter type="insert_column" column="0" value="equCab2chrM"/>
            <filter type="insert_column" column="0" value="equCab2"/>
            <filter type="metadata_value" ref="output" name="dbkey" column="1" />
        </option>
    </action>
</actions>
```
]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:group ref="ActionsElement" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>
  <xs:group name="ActionsElement">
    <xs:choice>
      <xs:element name="action" type="Action"/>
      <xs:element name="conditional" type="ActionsConditional"/>
    </xs:choice>
  </xs:group>
  <xs:complexType name="Action">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

This directive is contained within an output ``data``'s  ``actions`` directive
(either directly or beneath a parent ``conditional`` tag). This directive
describes modifications to either the output's format or metadata (based on
whether ``type`` is ``format`` or ``metadata``).

See [actions](#tool-outputs-data-actions) documentation for examples
of this directive.

]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="option" type="ActionsOption" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="type" type="ActionType" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en">Type of action (either ``format`` or
``metadata`` currently).</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="name" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">If ``type="metadata"``, the name of the
metadata element.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="default" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">If ``type="format"``, the default format
if none of the nested options apply.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="ActionsOption">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[
1. Load options from a data table, a parameter (or its metadata), or a file
2. Filter the options using all filters defined by the contained ``filter`` tags.
3. Chose a value in a given line (``offset``) and ``column``

The options can be considered as a table where each line is an option. The values
in the columns can be used for filtering.

The different data sources can be loaded as follows:

- ``from_data_table``: load the options from the data table with the given ``name``.
- ``from_param``: Initialize a single option containing the value of the
  referred parameter (``name``) or its metadata (``param_attribute``)
- ``from_file``: Load the file the given ``name`` (in Galaxy's tool data path), columns
  are defined by the given ``separator`` (default is tab).
      ]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="filter" type="ActionsConditionalFilter" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="type" type="ActionsOptionType" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
Source of the tabular data ``from_data_table``, ``from_param``, or ``from_file``.
        ]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="name" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
Name of the referred data table, parameter, or file (required).
        ]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="column" type="xs:integer">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
The column to choose the value from (required)
        ]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="offset" type="xs:integer">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
The row (of the options) to choose the value from (by default -1, ie. last row)
        ]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="param_attribute" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
Applies to ``from_param``. The attribute of the parameter to use.
        ]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="ActionsConditional">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

This directive is contained within an output ``data``'s  ``actions`` directive.
This directive describes the state of the inputs required to apply an ``action``
(specified as children of the child ``when`` directives to this element) to an
output.

See [actions](#tool-outputs-data-actions) documentation for examples
of this directive.

]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="when" type="ActionsConditionalWhen" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="name" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en">Name of the input parameter to base
conditional logic on. The value of this parameter will be matched against nested
``when`` directives.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="ActionsConditionalWhen">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

See [actions](#tool-outputs-data-actions) documentation for examples
of this directive.

      ]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:group ref="ActionsElement" minOccurs="1" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="value" type="xs:string" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en">Value to match conditional input value
against. This needs to be the python string representation of the parameter value,
e.g. ``True`` or ``False`` if the referred parameter is a boolean.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="datatype_isinstance" type="xs:string" use="optional">
      <xs:annotation>
        <xs:documentation xml:lang="en">Datatype to match against (if ``value`` is unspecified). This should be the short string describing the format (e.g. ``interval``).</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="ActionsConditionalFilter">
    <xs:annotation>
      <xs:documentation xml:lang="en"/>
    </xs:annotation>
    <xs:attribute name="type" type="ActionsConditionalFilterType" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
``param_value``

- get the value of a refered parameter (``ref``) or the value given by ``value``
  - if ``param_attribute`` is given the corresponding attribute of the value of the reffered parameter is used ``ref``
- cast this value with the function given by ``cast``
- compare the each the value in the column given by ``column`` (also casted) with the determined value using the function given by ``compare``
- if the result of the comparison is equal to the boolean given by ``keep`` the value is kept

``insert_column``

- insert a column with a value in the options
  - if ``column`` is given then the column is inserted before this column, otherwise the column is appended
  - the value can be given by ``ref`` or ``value``

``column_strip``

Strip (remove certain characters from the suffix / prefix) values in a column.
The characters to strip can be given by ``strip`` (deafult is whitespace
characters)

``multiple_splitter``

Split the values in a ``column`` by a given ``separator``. And replace the
original column with the with columns containing the result of splitting.

``column_replace``

Replace values in a column. The old and new values can be given

- as static values ``old_value`` or ``new_value``
- dynamically by the contents in (another) column ``old_column`` or ``new_colum``

``metadata_value``

Filter values in ``column`` by the metadata element ``name`` of the referred
parameter ``ref`` depending on the results of the comparison function given by
with ``compare`` and the value of ``keep`` (i.e. if the result of the
comparision is equal to ``keep`` then keep the option).

``boolean``

Cast the values in ``column`` using the cast function given by ``cast``
(unaccessible / uncastable values are interpreted as False).  The result of this
cast is then casted with the bool function. If the final result is equal to
``keep`` the option.

``string_function``

Apply a string function to the values in ``column``. The string function is given by ``name``.

        ]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="compare" type="CompareType">
      <xs:annotation>
        <!-- TOOD xsd only allows startswith and re_search code also supports eq, neq, gt, gte, lt, lte, in, endswith -->
        <xs:documentation xml:lang="en"><![CDATA[
Function to use for the comparision. One of startswith, re_search.
Applies to: ``param_value``, ``metadata_value``
        ]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="ref" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
Name of an input parameter (parameters in conditionals or sections are referred using the dot syntax, e.g. ``cond.paramname``).
Applies to ``param_value``, ``insert_column``, ``metadata_value``
        ]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="value" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
Fixed value to use for the comparison.
Applies to ``param_value``, ``insert_column``
        ]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="column" type="xs:integer">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
Column of the options (0 based).
Applies to ``param_value``, ``insert_column``, ``column_strip``, ``multiple_splitter``, ``column_replace``, ``metadata_value``, ``boolean``, ``string_function``
        ]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="keep" type="PermissiveBoolean">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
Keep the value if the filter condition is met. default: true
Applies to ``param_value``, ``metadata_value``, ``boolean``
        ]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="cast" type="xs:string">
      <xs:annotation>
        <!-- float might be nice -->
        <xs:documentation xml:lang="en"><![CDATA[
one of string_as_bool, int, str function used for casting the value.
Applies to ``param_value``, ``boolean``</xs:documentation>
        ]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="iterate" type="PermissiveBoolean">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
Applies to ``insert_column``. Default is ``False``</xs:documentation>
        ]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="param_attribute" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">
Which atttribute of the parameter value referred by ``ref`` to use. Separate with ``.``.
Applies to ``param_value``</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="separator" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Applies to ``multiple_splitter``</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="strip" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Applies to ``column_strip``. The given string is removed from the start or end of the column.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="old_column" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Applies to ``column_replace``</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="old_value" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Applies to ``column_replace``</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="new_column" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Applies to ``column_replace``</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="new_value" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Applies to ``column_replace``</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="name" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
For ``metadata_value`` this is the name of the metadata to use. For ``string``
function the string function to use (currently ``lower`` or ``upper``).
Applies to ``metadata_value``, ``string_function``
        ]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="EnvironmentVariables">
    <xs:annotation>
      <xs:documentation xml:lang="en">
This directive should contain one or more ``environment_variable`` definition.
      </xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="environment_variable" type="EnvironmentVariable" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="EnvironmentVariable">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

This directive defines an environment variable that will be available when the
tool executes. The body should be a Cheetah template block that may reference
the tool's inputs as demonstrated below.

### Example

The following demonstrates a couple ``environment_variable`` definitions.

```xml
<environment_variables>
    <environment_variable name="INTVAR">$inttest</environment_variable>
    <environment_variable name="IFTEST">#if int($inttest) == 3
ISTHREE
#else#
NOTTHREE
#end if#</environment_variable>
    </environment_variables>
</environment_variables>
```

If these environment variables are used in another Cheetah context, such as in
the ``command`` block, the ``$`` used indicate shell expansion of a variable
should be escaped with a ``\`` so prevent it from being evaluated as a Cheetah
variable instead of shell variable.

```xml
<command>
    echo "\$INTVAR"  >  $out_file1;
    echo "\$IFTEST"  >> $out_file1;
</command>
```

### inject

The Galaxy user's API key can be injected into an environment variable by setting ``inject``
attribute to ``api_key`` (e.g. ``inject="api_key"``).

```xml
<environment_variables>
    <environment_variable name="GALAXY_API_KEY" inject="api_key" />
</environment_variables>
```

The framework allows setting this via environment variable and not via templating variables
in order to discourage setting the actual values of these keys as command line arguments.
On shared systems this provides some security by preventing a simple process listing command
from exposing keys.
]]></xs:documentation>
    </xs:annotation>
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="name" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en">Name of the environment variable to
define.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="inject" type="EnvironmentVariableInject" gxdocs:added="19.09">
          <xs:annotation>
            <xs:documentation xml:lang="en">Special variable to inject into the environment variable. Currently 'api_key' is the only option and will cause the user's API key to be injected via this environment variable.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="strip" type="PermissiveBoolean" default="false">
          <xs:annotation>
            <xs:documentation xml:lang="en">Whether to strip leading and trailing whitespace from the calculated value before exporting the environment variable.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:simpleType name="EnvironmentVariableInject">
    <xs:annotation>
      <xs:documentation xml:lang="en"/>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="api_key"/>
      <xs:enumeration value="entry_point_path_for_label"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:complexType name="ConfigFiles">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[See
[xy_plot.xml](https://github.com/galaxyproject/tools-devteam/blob/main/tools/xy_plot/xy_plot.xml)
for an example of how this tag set is used in a tool. This tag set is a
container for ``<configfile>`` and ``<inputs>`` tag sets - which can be used
to setup configuration files for use by tools.]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:group ref="ConfigFilesElement" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>
  <xs:group name="ConfigFilesElement">
    <xs:choice>
      <xs:element name="inputs" type="ConfigInputs"/>
      <xs:element name="file_sources" type="ConfigFileSources"/>
      <xs:element name="configfile" type="ConfigFile"/>
    </xs:choice>
  </xs:group>
  <xs:complexType name="ConfigFile">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

This tag set is contained within the ``<configfiles>`` tag set. It allows for
the creation of a temporary file for file-based parameter transfer.

*Example*

The following is taken from the [xy_plot.xml](https://github.com/galaxyproject/tools-devteam/blob/main/tools/xy_plot/xy_plot.xml)
tool config.

```xml
<configfiles>
    <configfile name="script_file">
      ## Setup R error handling to go to stderr
      options(show.error.messages=F, error = function () { cat(geterrmessage(), file=stderr()); q("no", 1, F) })
      ## Determine range of all series in the plot
      xrange = c(NULL, NULL)
      yrange = c(NULL, NULL)
      #for $i, $s in enumerate($series)
          s${i} = read.table("${s.input.get_file_name()}")
          x${i} = s${i}[,${s.xcol}]
          y${i} = s${i}[,${s.ycol}]
          xrange = range(x${i}, xrange)
          yrange = range(y${i}, yrange)
      #end for
      ## Open output PDF file
      pdf("${out_file1}")
      ## Dummy plot for axis / labels
      plot(NULL, type="n", xlim=xrange, ylim=yrange, main="${main}", xlab="${xlab}", ylab="${ylab}")
      ## Plot each series
      #for $i, $s in enumerate($series)
          #if $s.series_type['type'] == "line"
              lines(x${i}, y${i}, lty=${s.series_type.lty}, lwd=${s.series_type.lwd}, col=${s.series_type.col})
          #elif $s.series_type.type == "points"
              points(x${i}, y${i}, pch=${s.series_type.pch}, cex=${s.series_type.cex}, col=${s.series_type.col})
          #end if
      #end for
      ## Close the PDF file
      devname = dev.off()
    </configfile>
</configfiles>
```

This file is then used in the ``command`` block of the tool as follows:

```xml
<command>bash '$__tool_directory__/r_wrapper.sh' '$script_file'</command>
```

]]></xs:documentation>
    </xs:annotation>
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="name" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en">Cheetah variable used to reference
the path to the file created with this directive.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="filename" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en">Path relative to the working directory of the tool for the configfile created in response to this directive.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="ConfigInputs">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[

This tag set is contained within the ``<configfiles>`` tag set. It tells Galaxy to
write out a JSON representation of the tool parameters.

*Example*

The following will create a Cheetah variable that can be evaluated as ``$inputs`` that
will contain the tool parameter inputs.

```xml
<configfiles>
    <inputs name="inputs" />
</configfiles>
```

The following will instead write the inputs to the tool's working directory with
the specified name (i.e. ``inputs.json``).

```xml
<configfiles>
    <inputs name="inputs" filename="inputs.json" />
</configfiles>
```

A contrived example of a tool that uses this is the test tool
[inputs_as_json.xml](https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/inputs_as_json.xml).

By default this file will not contain paths for data or collection inputs. To include simple
paths for data or collection inputs set the ``data_style`` attribute to ``paths`` (see [inputs_as_json_with_paths.xml](https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/inputs_as_json_with_paths.xml) for an example).
To include a dictionary with element identifiers, datatypes, staging paths, paths and metadata files set the ``data_style`` attribute to ``staging_path_and_source_path`` (element identifiers and datatypes are available since 24.0).
An example tool that uses ``staging_path_and_source_path`` is [inputs_as_json_with_staging_path_and_source_path.xml](https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/inputs_as_json_with_staging_path_and_source_path.xml)

Note that the element identifiers are stored as lists, where the last element is the actual element identifier of the dataset
and the other elements the identifiers of the collections containing the dataset.

For tools with profile >= 20.05 a select with ``multiple="true"`` is rendered as an array which is empty if nothing is selected. For older profile versions select lists are rendered as comma separated strings or a literal ``null`` in case nothing is selected.
]]></xs:documentation>
    </xs:annotation>
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="name" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en"><![CDATA[
Cheetah variable to populate the path to the inputs JSON file created in
response to this directive.
]]></xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="filename" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en">Path relative to the working directory of the tool for the inputs JSON file created in response to this directive.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="data_style" type="InputsConfigfileDatastyleType">
          <xs:annotation>
            <xs:documentation xml:lang="en">Set to 'paths' to include dataset paths in the resulting file. Set to 'staging_path_and_source_path' to include element identifiers, datatype, staging path, a source path and all metadata files.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="ConfigFileSources">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[
]]></xs:documentation>
    </xs:annotation>
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="name" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en"><![CDATA[
Cheetah variable to populate the path to the inputs JSON file created in
response to this directive.
]]></xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="filename" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en">Path relative to the working directory of the tool for the file sources JSON configuration file created in response to this directive.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="VersionCommand">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[Specifies the command to be run in
order to get the tool's version string. The resulting value will be found in the
"Info" field of the history dataset.

Unlike the [command](#tool-command) tag, with the exception of the string
``$__tool_directory__`` this value is taken as a literal and so there is no
need to escape values like ``$`` and command inputs are not available for variable
substitution.

### Examples

A simple example for a [TopHat](https://ccb.jhu.edu/software/tophat/index.shtml)
tool definition might just be:

```xml
<version_command>tophat -version</version_command>
```

An example that leverages a Python script (e.g. ``count_reads.py``) shipped with
the tool might be:

```xml
<version_command>python '$__tool_directory__/count_reads.py'</version_command>
```

Examples are included in the test tools directory including:

- [version_command_plain.xml](https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/version_command_plain.xml)
- [version_command_tool_dir.xml](https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/version_command_tool_dir.xml)
- [version_command_interpreter.xml](https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/version_command_interpreter.xml) (*deprecated*)

]]></xs:documentation>
    </xs:annotation>
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="interpreter" type="xs:string">
          <xs:annotation>
            <xs:documentation xml:lang="en"><![CDATA[*Deprecated*. This will prefix the version command with the value of this attribute (e.g. ``python`` or ``perl``) and the tool directory, in order to run an executable file shipped with the tool. It is recommended to instead use ``<interpreter> '$__tool_directory__/<executable_name>'`` in the tag content. If this attribute is not specified, the tag should contain a Bash command calling executable(s) available in the ``$PATH``, as modified after loading the requirements.]]></xs:documentation>
          </xs:annotation>
        </xs:attribute>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="RequestParameterTranslation">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[See [/tools/data_source/ucsc_tablebrowser.xml](https://github.com/galaxyproject/galaxy/blob/dev/tools/data_source/ucsc_tablebrowser.xml) for an example of how to use this tag set. This tag set is used only in "data_source" tools (i.e. whose ``tool_type`` attribute is ``data_source`` or ``data_source_async``). This tag set contains a set of [request_param](#tool-request-param-translation-request-param) elements.]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="request_param" minOccurs="0" maxOccurs="unbounded" type="RequestParameter"/>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="RequestParameter">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[Contained within the [request_param_translation](#tool-request-param-translation) tag set (used only in "data_source" tools). The external data source application may send back parameter names like "GENOME" which must be translated to "dbkey" in Galaxy.]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:group ref="RequestParameterElement" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="galaxy_name" type="RequestParameterGalaxyNameType" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en">
          Each of these maps directly to a ``remote_name`` value
        </xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="remote_name" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en">
          The string representing the name of the parameter in the remote data source
        </xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="missing" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">
          The default value to use for ``galaxy_name`` if the ``remote_name`` parameter is not included in the request
        </xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:simpleType name="RequestParameterGalaxyNameType">
    <xs:annotation>
      <xs:documentation xml:lang="en"/>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="URL"/>
      <xs:enumeration value="URL_method"/>
      <xs:enumeration value="dbkey"/>
      <xs:enumeration value="organism"/>
      <xs:enumeration value="table"/>
      <xs:enumeration value="position"/>
      <xs:enumeration value="description"/>
      <xs:enumeration value="name"/>
      <xs:enumeration value="info"/>
      <xs:enumeration value="data_type"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:group name="RequestParameterElement">
    <xs:choice>
      <xs:element name="append_param" type="RequestParameterAppend"/>
      <xs:element name="value_translation" type="RequestParameterValueTranslation"/>
    </xs:choice>
  </xs:group>
  <xs:complexType name="RequestParameterAppend">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[Optionally contained within the [request_param](#tool-request-param-translation-request-param) element if ``galaxy_name="URL"``. Some remote data sources (e.g., Gbrowse, Biomart) send parameters back to Galaxy in the initial response that must be added to the value of "URL" prior to Galaxy sending the secondary request to the remote data source via URL.]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="value" minOccurs="0" maxOccurs="unbounded" type="RequestParameterAppendValue"/>
    </xs:sequence>
    <xs:attribute name="separator" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
The text to use to join the requested parameters together (example ``separator="&amp;"``).
        ]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="first_separator" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
The text to use to join the ``request_param`` parameters to the first requested parameter (example ``first_separator="?"``).
        ]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="join" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
The text to use to join the param name to its value (example ``join="="``).
        ]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="RequestParameterAppendValue">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[Contained within the [append_param](#tool-request-param-translation-request-param-append-param) tag set. Allows for appending a param name / value pair to the value of URL.

Example:

```xml
<request_param_translation>
    <request_param galaxy_name="URL" remote_name="URL" missing="">
        <append_param separator="&amp;" first_separator="?" join="=">
            <value name="_export" missing="1" />
        </append_param>
    </request_param>
</request_param_tranlsation>
```
]]></xs:documentation>
    </xs:annotation>
    <xs:attribute name="name" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
Any valid HTTP request parameter name. The name / value pair must be received from the remote data source and will be appended to the value of URL as something like ``"&_export=1"`` (e.g. ``name="_export"``).
]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="missing" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[Must be a valid HTTP request parameter value (e.g. ``missing="1"``).]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="RequestParameterValueTranslation">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[Optionally contained within the [request_param](#tool-request-param-translation-request-param) tag set. The parameter value received from a remote data source may be named differently in Galaxy, and this tag set allows for the value to be appropriately translated.]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="value" minOccurs="0" maxOccurs="unbounded" type="RequestParameterValueTranslationValue"/>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="RequestParameterValueTranslationValue">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[Contained within the [value_translation](#tool-request-param-translation-request-param-value-translation) tag set - allows for changing the data type value to something supported by Galaxy.

Example:

```xml
<request_param_translation>
    <request_param galaxy_name="data_type" remote_name="hgta_outputType" missing="bed" >
        <value_translation>
            <value galaxy_value="tabular" remote_value="primaryTable" />
        </value_translation>
    </request_param>
</request_param_tranlsation>
```
]]></xs:documentation>
    </xs:annotation>
    <xs:attribute name="galaxy_value" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[
The target value (e.g. for setting data format: the list of supported data formats is contained in the
[/config/datatypes_conf.xml.sample](https://github.com/galaxyproject/galaxy/blob/dev/config/datatypes_conf.xml.sample).
]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="remote_value" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en"><![CDATA[The value supplied by the remote data source application]]></xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="Stdio">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[Tools write the bulk of useful data to datasets, but they can also write messages to standard I/O (stdio) channels known as standard output (stdout) and standard error (stderr). Both stdout and stderr are typically written to the executing program's console or terminal. Previous versions of Galaxy checked stderr for execution errors - if any text showed up on stderr, then the tool's execution was marked as failed. However, many tools write messages to stderr that are not errors, and using stderr allows programs to redirect other interesting messages to a separate file. Programs may also exit with codes that indicate success or failure. One convention is for programs to return 0 on success and a non-zero exit code on failure.

Legacy tools (ones with ``profile`` unspecified or a ``profile`` of less than
16.04) will default to checking stderr for errors as described above. Newer
tools will instead treat an exit code other than 0 as an error. The
``detect_errors`` on ``command`` can swap between these behaviors but the
``stdio`` directive allows more options in defining error conditions (though
these aren't always intuitive).

With ``stdio`` directive, Galaxy can use regular expressions to scan stdout and
stderr, and it also allows exit codes to be scanned for ranges. The ``<stdio>``
tag has two subtags, ``<regex>`` and ``<exit_code>``, to define regular
expressions and exit code processing, respectively. They are defined below. If a
tool does not have any valid ``<regex>`` or ``<exit_code>`` tags, then Galaxy
will use the previous technique for finding errors.

A note should be made on the order in which exit codes and regular expressions
are applied and how the processing stops. Exit code rules are applied before
regular expression rules. The rationale is that exit codes are more clearly
defined and are easier to check computationally, so they are applied first. Exit
code rules are applied in the order in which they appear in the tool's
configuration file, and regular expressions are also applied in the order in
which they appear in the tool's configuration file. However, once a rule is
triggered that causes a fatal error, no further rules are
checked.]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:group ref="StdioElement" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>
  <xs:group name="StdioElement">
    <xs:choice>
      <xs:element name="regex" type="Regex"/>
      <xs:element name="exit_code" type="ExitCode"/>
    </xs:choice>
  </xs:group>
  <xs:complexType name="ExitCode">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[
Tools may use exit codes to indicate specific execution errors. Many programs use 0 to indicate success and non-zero exit codes to indicate errors. Galaxy allows each tool to specify exit codes that indicate errors. Each ``<exit_code>`` tag defines a range of exit codes, and each range can be associated with a description of the error (e.g., "Out of Memory", "Invalid Sequence File") and an error level. The description just describes the condition and can be anything. The error level is either log, warning, fatal error, or fatal_oom. A warning means that stderr will be updated with the error's description. A fatal error means that the tool's execution will be marked as having an error and the workflow will stop. A fatal_oom indicates an out of memory condition and the job might be resubmitted if Galaxy is configured appropriately. Note that, if the error level is not supplied, then a fatal error is assumed to have occurred.

The exit code's range can be any consecutive group of integers. More advanced ranges, such as noncontiguous ranges, are currently not supported. Ranges can be specified in the form "m:n", where m is the start integer and n is the end integer. If ":n" is specified, then the exit code will be compared against all integers less than or equal to n. If "m:" is used, then the exit code will be compared against all integers greater than or equal to m. If the exit code matches, then the error level is applied and the error's description is added to stderr. If a tool's exit code does not match any of the supplied ``<exit_code>`` tags' ranges, then no errors are applied to the tool's execution.

Note that most Unix and Linux variants only support positive integers 0 to 255 for exit codes. If an exit code falls outside of this range, the usual convention is to only use the lower 8 bits for the exit code. The only known exception is if a job is broken into subtasks using the tasks runner and one of those tasks is stopped with a POSIX signal. (Note that signals should be used as a last resort for terminating processes.) In those cases, the task will receive -1 times the signal number. For example, suppose that a job uses the tasks runner and 8 tasks are created for the job. If one of the tasks hangs, then a sysadmin may choose to send the "kill" signal, SIGKILL, to the process. In that case, the task (and its job) will exit with an exit code of -9. More on POSIX signals can be found on [Wikipedia](https://en.wikipedia.org/wiki/Signal_(IPC)) as well as on the man page for "signal" (``man 7 signal``).

The ``<exit_code>`` tag's supported attributes are as follows:

* ``range``: This indicates the range of exit codes to check. The range can be one of the following:
  * ``n``: the exit code will only be compared to n;
  * ``m:n``: the exit code must be greater than or equal to m and less than or equal to n;
  * ``m:``: the exit code must be greater than or equal to m;
  * ``:n``: the exit code must be less than or equal to n.
* ``level``: This indicates the error level of the exit code. If no level is specified, then the fatal error level will be assumed to have occurred. The level can have one of following values:
  * ``log``, ``qc``, and ``warning``: If an exit code falls in the given range, then a description of the error will be added to the beginning of the source, prepended with either 'QC:', 'Log:' or 'Warning:'. This will not cause the tool to fail.
  * ``fatal``: If an exit code falls in the given range, then a description of the error will be added to the beginning of stderr. A fatal-level error will cause the tool to fail.
  * ``fatal_oom``: If an exit code falls in the given range, then a description of the error will be added to the beginning of stderr. Depending on the job configuration, a fatal_oom-level error will cause the tool to be resubmitted or fail.
* ``description``: This is an optional description of the error that corresponds to the exit code.

The following is an example of the ``<exit_code>`` tag:

```xml
<stdio>
    <exit_code range="3:5" level="warning" description="Low disk space" />
    <exit_code range="6:" level="fatal" description="Bad input dataset" />
    <!-- Catching fatal_oom allows the job runner to potentially resubmit to a resource with more
         memory if Galaxy is configured to do this. -->
    <exit_code range="2" level="fatal_oom" description="Out of Memory" />
</stdio>
```

If the tool returns 0 or 1, then the tool will not be marked as having an error.
If the exit code is 2, then the tool will fail with the description ``Out of
Memory`` added to stderr. If the tool returns 3, 4, or 5, then the tool will not
be marked as having failed, but ``Low disk space`` will be added to stderr.
Finally, if the tool returns any number greater than or equal to 6, then the
description ``Bad input dataset`` will be added to stderr and the tool will be
marked as having failed.

]]></xs:documentation>
    </xs:annotation>
    <xs:attribute name="range" type="RangeType" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en">Exit code range. Can be a single number or a range given by ``start:end``, where start and end are integers, if omitted negative or positive infinity is assumed</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="level" type="LevelType">
      <xs:annotation>
        <xs:documentation xml:lang="en">Error level: one of ``qc``, ``warning``, ``log``, ``fatal`` (default), ``fatal_oom``</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="description" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">Description. Error message presented to the user</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="Regex">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[
A regular expression defines a pattern of characters. The patterns include the following:

* ``GCTA``, which matches on the fixed string "GCTA";
* ``[abcd]``, which matches on the characters a, b, c, or d;
* ``[CG]{12}``, which matches on 12 consecutive characters that are C or G;
* ``a.*z``, which matches on the character "a", followed by 0 or more characters of any type, followed by a "z";
* ``^X``, which matches the letter X at the beginning of a string;
* ``Y$``, which matches the letter Y at the end of a string.

There are many more possible regular expressions. A reference to all supported
regular expressions can be found under
[Python Regular Expression Syntax](https://docs.python.org/3/library/re.html#regular-expression-syntax).

A regular expression includes the following attributes:

* ``source``: This tells whether the regular expression should be matched against stdout, stderr, or both. If this attribute is missing or is incorrect, then both stdout and stderr will be checked. The source can be one of the following values:
  * ``stdout``: the regular expression will be applied to stdout;
  * ``stderr``: the regular expression will be applied to stderr;
  * ``both``: the regular expression will be applied to both stderr and stdout (which is the default case).
* ``match``: This is the regular expression that will be used to match against stdout and/or stderr. If the ``<regex>`` tag does not contain the match attribute, then the ``<regex>`` tag will be ignored. The regular expression can be any valid Python regular expression. All regular expressions are performed case insensitively. For example, if match contains the regular expression "actg", then the regular expression will match against "actg", "ACTG", "AcTg", and so on. Also note that, if double quotes (") are to be used in the match attribute, then the value " can be used in place of double quotes. Likewise, if single quotes (') are to be used in the match attribute, then the value ' can be used if necessary.
* ``level``: This works very similarly to the ``<exit_code>`` tag, except that, when a regular expression matches against its source, the description is added to the beginning of the source. For example, if stdout matches on a regular expression, then the regular expression's description is added to the beginning of stdout (instead of stderr). If no level is specified, then the fatal error level will be assumed to have occurred. The level can have one of following values:
  * ``log``, ``qc``, and ``warning``: If the regular expression matches against its source input (i.e., stdout and/or stderr), then a description of the error will be added to the beginning of the source, prepended with either 'QC:', 'Log:', or 'Warning:'. This will not cause the tool to fail.
  * ``fatal``: If the regular expression matches against its source input, then a description of the error will be added to the beginning of the source. A fatal-level error will cause the tool to fail.
  * ``fatal_oom``: In contrast to fatal the job might be resubmitted if possible according to the job configuration.
* ``description``: Just like its ``exit_code`` counterpart, this is an optional description of the regular expression that has matched.

The following is an example of regular expressions that may be used:

```xml
<stdio>
    <regex match="low space"
           source="both"
           level="warning"
           description="Low space on device" />
    <regex match="error"
           source="stdout"
           level="fatal"
           description="Unknown error encountered" />
    <!-- Catching fatal_oom allows the job runner to potentially resubmit to a resource with more
         memory if Galaxy is configured to do this. -->
    <regex match="out of memory"
           source="stdout"
           level="fatal_oom"
           description="Out of memory error occurred" />
    <regex match="[CG]{12}"
           description="Fatal error - CG island 12 nts long found" />
    <regex match="^Branch A"
           level="warning"
           description="Branch A was taken in execution" />
</stdio>
```

The regular expression matching proceeds as follows. First, if either stdout or
stderr match on ``low space``, then a warning is registered. If stdout contained
the string ``---LOW SPACE---``, then stdout has the string ``Warning: Low space
on device`` added to its beginning. The same goes for if stderr had contained the
string ``low space``. Since only a warning could have occurred, the processing
continues.

Next, the regular expression ``error`` is matched only against stdout. If stdout
contains the string ``error`` regardless of its capitalization, then a fatal
error has occurred and the processing stops. In that case, stdout would be
prepended with the string ``Fatal: Unknown error encountered``. Note that, if
stderr contained ``error``, ``ERROR``, or ``ErRor`` then it would not matter -
stderr was not being scanned.

If the second regular expression does not match, the regular expression "out of memory"
is checked on stdout. If found, Galaxy tries to resubmit the job with more memory
if configured correctly, otherwise the job fails.

If the previous regular expressions does not match, then the fourth regular
expression is checked. The fourth regular expression does not contain an error
level, so an error level of ``fatal`` is assumed. The fourth regular expression
also does not contain a source, so both stdout and stderr are checked. The fourth
regular expression looks for 12 consecutive "C"s or "G"s in any order and in
uppercase or lowercase. If stdout contained ``cgccGGCCcGGcG`` or stderr
contained ``CCCCCCgggGGG``, then the regular expression would match, the tool
would be marked with a fatal error, and the stream that contained the
12-nucleotide CG island would be prepended with ``Fatal: Fatal error - CG island
12 nts long found``.

Finally, if the tool did not match any of the fatal errors, then the fifth
regular expression is checked. Since no source is specified, both stdout and
stderr are checked. If ``Branch A`` is at the beginning of stdout or stderr, then
a warning will be registered and the source that contained ``Branch A`` will be
prepended with the warning ``Warning: Branch A was taken in execution``.

Since Galaxy 24.0 groups defined in the regular expression are expanded in the
description (using the syntax of the [``expand`` function](https://docs.python.org/3/library/re.html#re.Match.expand)).
For the first ``regex`` in the following example the ``\1`` will be replaced
by the content of the text matching ``.*`` that follows on ``INFO: ``,
i.e. the content of the first group.
The second regular expression defines a named group ``error_message``
which then replaces the corresponding placeholder ``\g<error_message>`` in the
description. Note the quoting of the ``<`` and ``>`` characters in XML.

```xml
<stdio>
    <regex match="\(INFO\): (.*)"
           source="stderr"
           level="warning"
           description="\1" />
    <regex match="\(ERROR|WARNING\): (?P&lt;error_message&gt;.*)"
           source="stderr"
           level="fatal"
           description="\g&lt;error_message&gt;" />
</stdio>
```
]]></xs:documentation>
    </xs:annotation>
    <xs:attribute name="source" type="SourceType">
      <xs:annotation>
        <xs:documentation xml:lang="en">This tells whether the regular expression should be matched against stdout, stderr, or both. If this attribute is missing or is incorrect, then both stdout and stderr will be checked.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="match" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en">This is the regular expression that will be used to match against stdout and/or stderr.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="level" type="LevelType">
      <xs:annotation>
        <xs:documentation xml:lang="en">This works very similarly to the 'exit_code' tag, except that, when a regular expression matches against its source, the description is added to the beginning of the source.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="description" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">an optional description of the regular expression that has matched.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="ChangeFormat">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[
Change the format of an output depending on the value of another input paramter.
See [extract_genomic_dna.xml](https://github.com/galaxyproject/tools-iuc/blob/main/tools/extract_genomic_dna/extract_genomic_dna.xml)
or the test tool
[output_format.xml](https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/output_format.xml)
for simple examples of how this tag set is used in a tool. This tag set is
optionally contained within the ``<data>`` tag set and is the container tag set
for the following ``<when>`` tag set.]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="when" type="ChangeFormatWhen" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="ChangeFormatWhen">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[
If the value of referenced parameter has the specified value, the data type is
changed to the desired type.

### Examples

Assume that your tool config includes the following select list parameter
structure:

```xml
<param name="out_format" type="select" label="Output data type">
    <option value="fasta">FASTA</option>
    <option value="interval">Interval</option>
</param>
```

Then whenever the user selects the ``interval`` option from the select list, the
following structure in your tool config will override the ``format="fasta"`` setting
in the ``<data>`` tag set with ``format="interval"``.

```xml
<outputs>
    <data format="fasta" name="out_file1">
        <change_format>
            <when input="out_format" value="interval" format="interval" />
        </change_format>
    </data>
</outputs>
```

See
[extract_genomic_dna.xml](https://github.com/galaxyproject/tools-iuc/blob/main/tools/extract_genomic_dna/extract_genomic_dna.xml)
or the test tool
[output_format.xml](https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/output_format.xml)
for more examples.

For parameters that are nested in sections, conditionals, or repeats are accessed with object access syntax,
e.g. a parameter with name ``p`` that is in a conditional with name ``c``that is in a section with name ``s``
is referenced by ``s.c.p``"].
]]></xs:documentation>
    </xs:annotation>
    <xs:sequence/>
    <xs:attribute name="input" type="xs:string">
      <xs:annotation>
        <xs:documentation xml:lang="en">This attribute should be the name of
the desired input parameter (e.g. ``input="out_format"`` above). Parameters that are nested are accessed like an object.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="value" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en">This must be a possible value of the ``input``
parameter (e.g. ``value="interval"`` above), or of the deprecated ``input_dataset``'s
attribute.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="format" type="Format" use="required">
      <xs:annotation>
        <xs:documentation xml:lang="en">This value must be a supported data type
(e.g. ``format="interval"``). See
[/config/datatypes_conf.xml.sample](https://github.com/galaxyproject/galaxy/blob/dev/config/datatypes_conf.xml.sample)
for a list of supported formats.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="input_dataset" type="xs:string" gxdocs:deprecated="true">
      <xs:annotation>
        <xs:documentation xml:lang="en">*Deprecated*.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="attribute" type="xs:string" gxdocs:deprecated="true">
      <xs:annotation>
        <xs:documentation xml:lang="en">*Deprecated*.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="Citations">
    <xs:annotation>
      <xs:documentation xml:lang="en"><![CDATA[Tool files may declare one
citations element. Each citations element can contain one or more citation tag
elements - each of which specifies tool citation information using either a DOI
or a BibTeX entry.

These citations will appear at the bottom of the tool form in a formatted way
but the user will have to option to select RAW BibTeX for copying and pasting as
well. Likewise, the history menu includes an option allowing users to aggregate
all such citations across an analysis in a list of citations.

BibTeX entries for citations annotated with DOIs will be fetched by Galaxy from
https://doi.org/ and cached.

```xml
<citations>
   <!-- Example of annotating a citation using a DOI. -->
   <citation type="doi">10.1093/bioinformatics/btq281</citation>

   <!-- Example of annotating a citation using a BibTex entry. -->
   <citation type="bibtex">@ARTICLE{Kim07aninterior-point,
   author = {Seung-jean Kim and Kwangmoo Koh and Michael Lustig and Stephen Boyd and Dimitry Gorinevsky},
   title = {An interior-point method for large-scale l1-regularized logistic regression},
   journal = {Journal of Machine Learning Research},
   year = {2007},
   volume = {8},
   pages = {1519-1555}
   }</citation>
 </citations>
```

For more implementation information see the
[pull request](https://bitbucket.org/galaxy/galaxy-central/pull-requests/440/initial-bibtex-doi-citation-support-in/diff)
adding this feature. For more examples of how to add this to tools checkout the
following commits adding this to the
[NCBI BLAST+ suite](https://github.com/peterjc/galaxy_blast/commit/9d2e3906915895765ecc3f48421b91fabf2ccd8b),
[phenotype association tools](https://bitbucket.org/galaxy/galaxy-central/commits/39c983151fe328ff5d415f6da81ce5b21a7e18a4),
[MAF suite](https://bitbucket.org/galaxy/galaxy-central/commits/60f63d6d4cb7b73286f3c747e8acaa475e4b6fa8),
and [MACS2 suite](https://github.com/jmchilton/galaxytools/commit/184971dea73e236f11e82b77adb5cab615b8391b).

This feature was added to the August 2014 release of Galaxy, tools annotated
with citations will work in older releases of Galaxy but no citation information
will be available to the end user.
]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="citation" type="Citation" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="Citation">
    <xs:annotation>
      <xs:documentation xml:lang="en">Each citations element can contain one or
more ``citation`` tag elements - each of which specifies tool citation
information using either a DOI or a BibTeX entry.</xs:documentation>
    </xs:annotation>
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="type" type="CitationType" use="required">
          <xs:annotation>
            <xs:documentation xml:lang="en">Type of citation - currently ``doi``
and ``bibtex`` are the only supported options.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:simpleType name="CitationType">
    <xs:annotation>
      <xs:documentation xml:lang="en">Type of citation represented.</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="bibtex"/>
      <xs:enumeration value="doi"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="RequirementType">
    <xs:annotation>
      <xs:documentation xml:lang="en">Documentation for RequirementType</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="python-module"/>
      <xs:enumeration value="binary"/>
      <xs:enumeration value="package"/>
      <xs:enumeration value="set_environment"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="ResourceType">
    <xs:annotation>
      <xs:documentation xml:lang="en">Type of resource specification.</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="cores_min">
        <xs:annotation>
          <xs:documentation xml:lang="en">Minimum reserved number of CPU cores, if runtime allows it (not yet implemented in Galaxy).</xs:documentation>
        </xs:annotation>
      </xs:enumeration>
      <xs:enumeration value="cores_max">
        <xs:annotation>
          <xs:documentation xml:lang="en">Maximum reserved number of CPU cores, if runtime allows it (not yet implemented in Galaxy).</xs:documentation>
        </xs:annotation>
      </xs:enumeration>
      <xs:enumeration value="ram_min">
        <xs:annotation>
          <xs:documentation xml:lang="en">Minimum reserved RAM in mebibytes (2**20 bytes), if runtime allows it (not yet implemented in Galaxy).</xs:documentation>
        </xs:annotation>
      </xs:enumeration>
      <xs:enumeration value="ram_max">
        <xs:annotation>
          <xs:documentation xml:lang="en">Maximum reserved RAM in mebibytes (2**20 bytes), if runtime allows it (not yet implemented in Galaxy).</xs:documentation>
        </xs:annotation>
      </xs:enumeration>
      <xs:enumeration value="tmpdir_min">
        <xs:annotation>
          <xs:documentation xml:lang="en">Minimum reserved filesystem-based storage for the designated temporary directory in mebibytes (2**20 bytes), if runtime allows it (not yet implemented in Galaxy).</xs:documentation>
        </xs:annotation>
      </xs:enumeration>
      <xs:enumeration value="tmpdir_max">
        <xs:annotation>
          <xs:documentation xml:lang="en">Maximum reserved filesystem based storage for the designated temporary directory, in mebibytes (2**20 bytes), if runtime allows it (not yet implemented in Galaxy).</xs:documentation>
        </xs:annotation>
      </xs:enumeration>
      <xs:enumeration value="cuda_version_min">
        <xs:annotation>
          <xs:documentation xml:lang="en">Minimum CUDA (runtime link library) runtime version, if runtime allows it (not yet implemented in Galaxy).</xs:documentation>
        </xs:annotation>
      </xs:enumeration>
      <xs:enumeration value="cuda_compute_capability">
        <xs:annotation>
          <xs:documentation xml:lang="en">Minimum NVIDIA (hardware+driver) Compute capabilities (major, minor (can be a range or a list), if runtime allows it (not yet implemented in Galaxy).</xs:documentation>
        </xs:annotation>
      </xs:enumeration>
      <xs:enumeration value="gpu_memory_min">
        <xs:annotation>
          <xs:documentation xml:lang="en">Minimum Memory of the GPU in mebibytes, if runtime allows it (not yet implemented in Galaxy).</xs:documentation>
        </xs:annotation>
      </xs:enumeration>
      <xs:enumeration value="cuda_device_count_min">
        <xs:annotation>
          <xs:documentation xml:lang="en">Minimum CUDA device count, if runtime allows it (not yet implemented in Galaxy).</xs:documentation>
        </xs:annotation>
      </xs:enumeration>
      <xs:enumeration value="cuda_device_count_max">
        <xs:annotation>
          <xs:documentation xml:lang="en">Maximum CUDA device count, if runtime allows it (not yet implemented in Galaxy).</xs:documentation>
        </xs:annotation>
      </xs:enumeration>
      <xs:enumeration value="shm_size">
        <xs:annotation>
          <xs:documentation xml:lang="en"><![CDATA[Size of /dev/shm. The format is `<number><unit>`. <number> must be greater than 0. Unit is optional and can be `b` (bytes), `k` (kilobytes), `m` (megabytes), or `g` (gigabytes). If you omit the unit, the default is bytes. If you omit the size entirely, the value is `64m`.]]></xs:documentation>
        </xs:annotation>
      </xs:enumeration>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="ContainerType">
    <xs:annotation>
      <xs:documentation xml:lang="en">Type of container for tool execution.</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="docker"/>
      <xs:enumeration value="singularity"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="ToolTypeType">
    <xs:annotation>
      <xs:documentation xml:lang="en">Documentation for ToolTypeType</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="data_source"/>
      <xs:enumeration value="data_source_async"/>
      <xs:enumeration value="manage_data"/>
      <xs:enumeration value="interactive"/>
      <xs:enumeration value="expression"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="URLmethodType">
    <xs:annotation>
      <xs:documentation xml:lang="en">Documentation for URLmethodType</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="get"/>
      <xs:enumeration value="post"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="TargetType">
    <xs:annotation>
      <xs:documentation xml:lang="en">Documentation for TargetType</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="_top"/>
      <xs:enumeration value="_parent"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="MethodType">
    <xs:annotation>
      <xs:documentation xml:lang="en">Documentation for MethodType</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="basic"/>
      <xs:enumeration value="multi"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="DisplayType">
    <xs:annotation>
      <xs:documentation xml:lang="en">Documentation for DisplayType</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="checkboxes"/>
      <xs:enumeration value="radio"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="HierarchyType">
    <xs:annotation>
      <xs:documentation xml:lang="en">Documentation for HierarchyType</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="exact"/>
      <xs:enumeration value="recurse"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="ValidatorType">
    <xs:annotation>
      <xs:documentation xml:lang="en">Documentation for ValidatorType</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="empty_dataset"/>
      <xs:enumeration value="empty_extra_files_path"/>
      <xs:enumeration value="expression"/>
      <xs:enumeration value="regex"/>
      <xs:enumeration value="in_range"/>
      <xs:enumeration value="length"/>
      <xs:enumeration value="metadata"/>
      <xs:enumeration value="dataset_metadata_equal" gxdocs:added="23.1"/>
      <xs:enumeration value="unspecified_build"/>
      <xs:enumeration value="no_options"/>
      <xs:enumeration value="empty_field"/>
      <xs:enumeration value="dataset_metadata_in_file"/>
      <xs:enumeration value="dataset_metadata_in_data_table"/>
      <xs:enumeration value="dataset_metadata_not_in_data_table"/>
      <xs:enumeration value="value_in_data_table"/>
      <xs:enumeration value="value_not_in_data_table"/>
      <xs:enumeration value="dataset_metadata_in_range"/>
      <xs:enumeration value="dataset_ok_validator"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="FilterType">
    <xs:annotation>
      <xs:documentation xml:lang="en"/>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="data_meta"/>
      <xs:enumeration value="param_value"/>
      <xs:enumeration value="static_value"/>
      <xs:enumeration value="regexp"/>
      <xs:enumeration value="unique_value"/>
      <xs:enumeration value="multiple_splitter"/>
      <xs:enumeration value="attribute_value_splitter"/>
      <xs:enumeration value="add_value"/>
      <xs:enumeration value="remove_value"/>
      <xs:enumeration value="sort_by"/>
      <xs:enumeration value="data_table"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="ActionsConditionalFilterType">
    <xs:annotation>
      <xs:documentation xml:lang="en"/>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="param_value"/>
      <xs:enumeration value="insert_column"/>
      <xs:enumeration value="column_strip"/>
      <xs:enumeration value="multiple_splitter"/>
      <xs:enumeration value="attribute_value_splitter"/>
      <xs:enumeration value="column_replace"/>
      <xs:enumeration value="metadata_value"/>
      <xs:enumeration value="boolean"/>
      <xs:enumeration value="string_function"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="ActionType">
    <xs:annotation>
      <xs:documentation xml:lang="en">Documentation for ActionType</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="format"/>
      <xs:enumeration value="metadata"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="ActionsOptionType">
    <xs:annotation>
      <xs:documentation xml:lang="en">Documentation for ActionsOptionType</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="from_data_table"/>
      <xs:enumeration value="from_param"/>
      <xs:enumeration value="from_file"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="CompareType">
    <xs:annotation>
      <xs:documentation xml:lang="en">Documentation for CompareType</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="startswith"/>
      <xs:enumeration value="re_search"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="LevelType">
    <xs:annotation>
      <xs:documentation xml:lang="en">Documentation for LevelType</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="fatal_oom"/>
      <xs:enumeration value="fatal"/>
      <xs:enumeration value="warning"/>
      <xs:enumeration value="log"/>
      <xs:enumeration value="qc"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="RangeType">
    <xs:annotation>
      <xs:documentation xml:lang="en">Documentation for RangeType</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:pattern value="((-?\d+)?:(-?\d+)?)|(-?\d+)"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="SourceType">
    <xs:annotation>
      <xs:documentation xml:lang="en">Documentation for SourceType</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="stdout"/>
      <xs:enumeration value="stderr"/>
      <xs:enumeration value="both"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="TestOutputCompareType">
    <xs:annotation>
      <xs:documentation xml:lang="en">Type of comparison to use when comparing
test generated output files to expected output files. Currently valid value are
``diff`` (the default), ``re_match``, ``re_match_multiline``, ``contains``,
and ``image_diff``. In addition there is ``sim_size`` which is discouraged in
favour of a ``has_size`` assertion.</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="diff"/>
      <xs:enumeration value="re_match"/>
      <xs:enumeration value="sim_size"/>
      <xs:enumeration value="re_match_multiline"/>
      <xs:enumeration value="contains"/>
      <xs:enumeration value="image_diff"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="TestOutputMetricType">
    <xs:annotation>
      <xs:documentation xml:lang="en">If ``compare`` is set to ``image_diff``, this is the metric used to compute the distance between images for quantification of their difference. For intensity images, possible metrics are *mean absolute error* (``mae``, the default), *mean squared error* (``mse``), *root mean squared* error (``rms``), and the *Frobenius norm* (``fro``). In addition, for binary images and label maps (with multiple objects), ``iou`` can be used to compute *one minus* the *intersection over the union* (IoU). Object correspondances are established by taking the pair of objects, for which the IoU is highest (also see the ``pin_labels`` attribute), and the distance of the images is the worst value determined for any pair of corresponding objects.</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="mae"/>
      <xs:enumeration value="mse"/>
      <xs:enumeration value="rms"/>
      <xs:enumeration value="fro"/>
      <xs:enumeration value="iou"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="PermissiveBoolean">
    <xs:annotation>
      <xs:documentation xml:lang="en">Documentation for PermissiveBoolean</xs:documentation>
    </xs:annotation>
    <xs:union>
      <xs:simpleType>
        <xs:restriction base="xs:boolean"/>
      </xs:simpleType>
      <xs:simpleType>
        <xs:restriction base="xs:string">
          <xs:enumeration value="true"/>
          <xs:enumeration value="false"/>
          <xs:enumeration value="True"/>
          <xs:enumeration value="False"/>
          <xs:enumeration value="yes"/>
          <xs:enumeration value="no"/>
          <xs:enumeration value="0"/>
          <xs:enumeration value="1"/>
        </xs:restriction>
      </xs:simpleType>
    </xs:union>
  </xs:simpleType>
  <xs:simpleType name="Bytes">
    <xs:annotation>
      <xs:documentation xml:lang="en">Number of bytes allowing for suffix (k|K|M|G|P|E)i? </xs:documentation>
    </xs:annotation>
    <xs:union>
      <xs:simpleType>
        <xs:restriction base="xs:integer">
         </xs:restriction>
      </xs:simpleType>
      <xs:simpleType>
        <xs:restriction base="xs:string">
          <xs:pattern value="(0|[1-9][0-9]*)([kKMGTPE]i?)?"/>
        </xs:restriction>
      </xs:simpleType>
    </xs:union>
  </xs:simpleType>
  
  <xs:simpleType name="Format">
    <xs:restriction base="xs:string">
      <xs:pattern value="[0-9a-z.-_]+"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="FormatList">
    <xs:restriction base="xs:string">
      <xs:pattern value="([a-z0-9._-]+)(,([a-z0-9._-]+))*"/>
    </xs:restriction>
  </xs:simpleType>
  
  <xs:complexType name="EdamTopics">
    <xs:annotation gxdocs:best_practices="tool-annotations-edam">
      <xs:documentation xml:lang="en"><![CDATA[
Container tag set for the ``<edam_topic>`` tags.
A tool can have any number of EDAM topic references.

```xml
<!-- Example: this tool is about 'Statistics and probability' (http://edamontology.org/topic_2269) -->
<edam_topics>
    <edam_topic>topic_2269</edam_topic>
</edam_topics>
```
]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="edam_topic" minOccurs="0" maxOccurs="unbounded">
        <xs:simpleType>
          <xs:restriction base="singleLineString">
            <xs:pattern value="topic_[0-9]{4}"/>
          </xs:restriction>
        </xs:simpleType>
      </xs:element>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="EdamOperations">
    <xs:annotation gxdocs:best_practices="tool-annotations-edam">
      <xs:documentation xml:lang="en"><![CDATA[
Container tag set for the ``<edam_operation>`` tags.
A tool can have any number of EDAM operation references.

```xml
<!-- Example: this tool performs a 'Conversion' operation (http://edamontology.org/operation_3434) -->
<edam_operations>
    <edam_operation>operation_3434</edam_operation>
</edam_operations>
```

]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="edam_operation" minOccurs="0" maxOccurs="unbounded">
        <xs:simpleType>
          <xs:restriction base="singleLineString">
            <xs:pattern value="operation_[0-9]{4}"/>
          </xs:restriction>
        </xs:simpleType>
      </xs:element>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="xrefs">
    <xs:annotation gxdocs:best_practices="tool-cross-references-bio-tools">
      <xs:documentation xml:lang="en"><![CDATA[
Container tag set for the ``<xref>`` tags.
A tool can refer multiple reference IDs.

```xml
   <!-- Example: this tool is dada2 -->
   <xrefs>
       <xref type="bio.tools">dada2</xref>
       <xref type="bioconductor">dada2</xref>
   </xrefs>
   <!-- https://bio.tools/dada2 -->
```

]]></xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="xref" type="xref" minOccurs="0" maxOccurs="unbounded">
      </xs:element>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="xref">
    <xs:annotation>
      <xs:documentation xml:lang="en">The ``xref`` element specifies reference
information according to a catalog.</xs:documentation>
    </xs:annotation>
    <xs:simpleContent>
      <xs:extension base="singleLineString">
        <xs:attribute name="type" type="xrefType" use="required">
          <xs:annotation>
            <xs:documentation xml:lang="en">Type of reference - currently ``bio.tools``, ``bioconductor``, and ``biii`` are
the only supported options.</xs:documentation>
          </xs:annotation>
        </xs:attribute>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:simpleType name="xrefType">
    <xs:annotation>
      <xs:documentation xml:lang="en">Type of Reference.</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="bio.tools"/>
      <xs:enumeration value="bioconductor"/>
      <xs:enumeration value="biii"/>
      <!--xs:enumeration value="whatelse"/-->
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="MacroImportType">
    <xs:restriction base="singleLineString">
      <xs:pattern value="[a-zA-Z0-9_\-\.]+.xml"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="singleLineString">
    <xs:annotation>
      <xs:documentation xml:lang="en">A string without newline characters.</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:whiteSpace value="collapse"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="DetectErrorType">
    <xs:restriction base="xs:string">
      <xs:enumeration value="default"/>
      <xs:enumeration value="exit_code"/>
      <xs:enumeration value="aggressive"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="CollectionType">
    <xs:annotation>
      <xs:documentation xml:lang="en">Allowed collection types</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:pattern value="(list|paired)([:](list|paired))*"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="CollectionTypeList">
    <xs:annotation>
      <xs:documentation xml:lang="en">Allowed collection types</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:pattern value="(list|paired)([:,](list|paired))*"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="InputsConfigfileDatastyleType">
    <xs:annotation>
      <xs:documentation xml:lang="en">Allowed collection types</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="paths"/>
      <xs:enumeration value="staging_path_and_source_path"/>
    </xs:restriction>
  </xs:simpleType>
</xs:schema>