Tools can often accept multiple input types, and that's something we want to reflect in Janis.
The simplest union types
It would be simple to add a Union(String, Int) operator into Janis and let the type system reflect this.
Localisation makes this harder
When you mix types that require localisation or secondary files. For example:
Union(String, File) is not easy to replicate in WDL:
if the input is a File, we want to localise the input, else we'll just pass the coerced string to this input.
Union(BamBai, CramCrai) is even harder to replicate in both.
If the input is an indexed bam, we'll index the main file and bam separately, the crai uses a different index.
Solution
It's not practical to generate a specification in CWL and WDL that can accurately reflect this case. Instead, we'll likely generate multiple versions of the workflow schema, depending on what the input(s) are. This way we won't necessarily clash if the same tool is used with different types of inputs.
Likely, the Union will have a default type for when you just translate it.
Backwards compatibility
This will add a new DataType called Union, the introduction of which should not affect current workflows. With internal changes relating to this, our biggest goal is to keep the current API as is, and changes would only be required for tools hoping to take advantage of this feature.
So we're anticipating that previous workflows will be compatible with no code changes.
Tools can often accept multiple input types, and that's something we want to reflect in Janis.
The simplest union types
It would be simple to add a
Union(String, Int)operator into Janis and let the type system reflect this.Localisation makes this harder
When you mix types that require localisation or secondary files. For example:
Union(String, File)is not easy to replicate in WDL:Union(BamBai, CramCrai)is even harder to replicate in both.Solution
It's not practical to generate a specification in CWL and WDL that can accurately reflect this case. Instead, we'll likely generate multiple versions of the workflow schema, depending on what the input(s) are. This way we won't necessarily clash if the same tool is used with different types of inputs.
Likely, the Union will have a default type for when you just translate it.
Backwards compatibility
This will add a new DataType called Union, the introduction of which should not affect current workflows. With internal changes relating to this, our biggest goal is to keep the current API as is, and changes would only be required for tools hoping to take advantage of this feature.
So we're anticipating that previous workflows will be compatible with no code changes.