Hi and thank you for the response !

I have a little few more questions. See below.

Jeremy Goecks wrote:
> This question is best directed to the galaxy-dev mailing list because
> it concerns developing around Galaxy, so I've moved it there.
>> However, if I understand it right, the idea of the XML tool config is
>> to provide a description of the galaxy graphical user interface
>> rather then a general description of the actual tool's interface.
> No, the XML config describes a tool in abstract/essence: inputs,
> parameters, and outputs. Rendering of a tool can be done any number of
> ways.
>> - param tag: I havent really understood how you define a parameter to
>> be mandatory or optional. I see when it is the child of the repeat
>> element that there is (maybe) a minimum defined. But when this is not
>> the case, how can I conclude that the parameter is optional vs.
>> mandatory ?
> Parameters have an 'optional' attribute. See here for details on tool
> and parameter config in general:
> http://wiki.galaxyproject.org/Admin/Tools/ToolConfigSyntax
For example lets consider the gatk's depth_of_coverage.xml together with
the gatk_macros.xml:
There is exactly one parameter (input_calculate_coverage_over_genes)
defined as optional. I know that most of the tools parameters are indeed
optional and a default value is internally assumed. As it is generally
the case of gatk that only the input, reference and output file and a
few more parameters have to be passed to the tool and the rest can be
omitted, i.e. are optional.
However, one might get the impression, that the conditional tag somehow
overlaps this: In the sense that the allowed parameter values are
enumerated (in combination with option tag) and a default value is
defined (and passed to the execution engine). Doing so the galaxy tool
interface finally presents these parameter option values to the user
(and the user can optionally select a non default value).
As an example see the parameter "--interval_set_rule UNION" (is rendered
when the advanced dialog is opened) which is an optional parameter that
is not explicitly marked as optional.

Question: How save is the optional attribute ? I mean how consequent are
you in this matter when the tool definition xml is to be created. Is
there any relation to the conditional tag ?

Another question: Have you ever thought about pipes. It seems that the
tool xml schema entirely ignores it. For instance one could easily tag
an input parameter to be able to read from stdin or to write to
stdout/stderr. Especially samtools and bedtools do support pipes. Is
there an obvious reason not to use it ?


Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

To search Galaxy mailing lists use the unified search at:

Reply via email to