[x] Include attribution information for the author(s) of the CWL tool or workflow description. Use unambiguous identifiers like ORCID.
[ ] In tool descriptions, list dependencies using short name(s) under SoftwareRequirement.
[ ] Include SciCrunch identifiers for dependencies in https://identifiers.org/rrid/RRID:SCR_NNNNNN format.
[ ] All input and output identifiers should reflect their conceptual identity. Use informative names like unaligned_sequences, reference_genome, phylogeny, or aligned_sequences instead of foo_input, foo_file, result, input, output, and so forth.
[ ] In tool descriptions, include a list of version(s) of the tool that are known to work with this description under SoftwareRequirement.
[ ] format should be specified for all input and output Files. Bioinformatics tools should use format identifiers from EDAM. See also iana:text/plain, iana:text/tab-separated-values with $namespaces: { iana: "https://www.iana.org/assignments/media-types/" }. Full IANA media type list(also known as MIME types). For non-bioinformatics tools use or build an appropriate ontology/controlled vocabulary in the same way.
[ ] Mark all input and output Files that are read from or written to in a streaming compatible way (only once, no random-access), as streamable: true.
[ ] Each CommandLineTool description should focus on a single operation only, even if the (sub)command is capable of more. Don’t overcomplicate your tool descriptions with options that you don’t need/use.
[x] Custom types should be defined with one external YAML per type definition for re-use.
[ ] Include a top level short label summarising the tool/workflow.
[ ] If useful, include a top level doc as well. This should provide a longer, more detailed description than was provided in the top level label (see above).
[ ] Use type: enum instead of type: string for elements with a fixed list of valid values.
[x] Evaluate all use of JavaScript for possible elimination or replacement. One common example: manipulating File names and paths? Consider whether one of the built-in in File properties like basename, nameroot, nameext, etc, could be used instead.
[ ] Give the tool description to a colleague (preferably at a different institution) to test and provide feedback.
http://www.commonwl.org/user_guide/rec-practices/
type: string
parameters for names of input or reference files/directories; usetype: File
ortype: Directory
as appropriate.SoftwareRequirement
.https://identifiers.org/rrid/RRID:SCR_NNNNNN
format.input
andoutput
identifiers should reflect their conceptual identity. Use informative names likeunaligned_sequences
,reference_genome
,phylogeny
, oraligned_sequences
instead offoo_input
,foo_file
,result
,input
,output
, and so forth.SoftwareRequirement
.iana:text/plain
,iana:text/tab-separated-values
with$namespaces: { iana: "https://www.iana.org/assignments/media-types/" }
. Full IANA media type list(also known as MIME types). For non-bioinformatics tools use or build an appropriate ontology/controlled vocabulary in the same way.File
s that are read from or written to in a streaming compatible way (only once, no random-access), asstreamable: true
.CommandLineTool
description should focus on a single operation only, even if the (sub)command is capable of more. Don’t overcomplicate your tool descriptions with options that you don’t need/use.label
summarising the tool/workflow.doc
as well. This should provide a longer, more detailed description than was provided in the top level label (see above).type: enum
instead oftype: string
for elements with a fixed list of valid values.File
names and paths? Consider whether one of the built-in inFile
properties likebasename
,nameroot
,nameext
, etc, could be used instead.