Core cwl tool architecture design

[jefferys]

Considering what the core architecture should be. The "cwl" language is implemented as a "SALAD" language, meaning a generic SALAD document parser would work, but probably require stuff not used by the CWL. As there is no SALAD parser for R (not that I expect that would be widely useful anyway) I think this package will implement only what is needed to represent cwl documents. This means there needs to be:

1. Code or functions that read a cwl document and convert it to an internal representation. This probably consists of a generic yml -> R object step, (package function?), and then a custom function to translate this generic object into a standard internal representation.
2. Code or functions that create and work with the internal representation.
3. Code or functions that write an internal representation out as a cwl document. Probably the reverse of 1, with a generic R object -> yml step (package function?) preceded by a custom function to translate the standard internal representation to an object that generates correct/expected yml.
4. Code or functions that validate a cwl document and/or a yml object and/or an internal representation object. This is only a structural/type validation, as there is no "values" in a cwl. Values come from a data yml file, the loading and management of which will be addressed in the next stage of development.

A cwl is actually itself just a "schema". One cwl object is used with multiple data files/instances, and is provided without data present so the cwl needs a stand-alone representation. It is important that this representation be usable with data in a simple way.

The parsing and the representation should be isolated from each other, and from the rest of the code as much as possible, in the unlikely event that a general SALAD parser implementation becomes available in R.

[jefferys]

I think that the only way to build this efficiently, rather than provide an "all possible options up front" design is to aim for directly running examples. In that vain I have created a project to build an alpha version that has an actual working runner, but only locally. The first goals will come from the CWL user guide.

[jefferys]

An outline of the api then looks like

 cwlRun( "tool.cwl", "instance.yml" )

or

 cwlToolObj <- cwlRead( "tool.cwl" )
 cwlDataObj <- <yaml_package::read>(data.yml)
 cwlRun( cwlToolObj, cwlDataObj )

Probably want a dry-run version of the cwlRun that prints the command string instead of running it.