vatlab/sos-docs

CWL is the name of a set of standards, not a system

Closed this issue · 3 comments

mr-c commented

There are many systems that can speak CWL, see http://www.commonwl.org/#Implementations

One doesn't install, buy, or rent CWL as if it was a system or platform; one uses software/platforms/systems that speaks or supports the CWL standards for representing workflows and their component tools.

The following documents refer to CWL as if it was a specific system

It would be great if the references to CWL were corrected; thanks!

BoPeng commented

Updated.

mr-c commented

Thank you @BoPeng

FYI: CWL workflows can be a single file, or multi-files. We find the multi-file version makes for more-reusable and sharable workflows/components.

Some CWL runner give a graphical interface with interactive usage. The Rabix Composer allows for a graphical construction of CWL workflows: https://github.com/rabix/composer

I think the assertion that Python is more readable than CWL syntax is interesting, but unsupported. Have you done a study?

CWL is freely available for commercial and non-commercial use, unlike SOS

BoPeng commented

Hi, @mr-c

Thanks for your comments. SoS is quite young and has not reached 1.0 yet and I am glad to hear opinions from developer of a much more mature workflow system.

SoS workflows can also consist of multiple files, we actually have directives such as %include, and %if %else etc, but because the design goal of SoS is "upfront", "readability" and "interactive", they are currently not documented and might be removed latter on. For components that should be modularized/separated, they can be defined as Python modules, partial scripts in other languages, external workflows and be used in a SoS script in several different ways. I do not want to argue with you which way (single or multiple files) is more readable because SoS and CWL come from different design ideas and SoS, as its name suggests, tends to be more "inclusive", and "integrative".

For GUI, we consider GUI as an unnecessary burden because it forces users away from their familiar working environments so that they have to debug/development in one environment and deploy in another. SoS also has a GUI (SoS Notebook based on Jupyter) with a very strong emphasis on smooth transition from interactive development to SoS workfow.

For readability, the main point is not Python is more readable than CWL/JS, it is about "additional syntax to make a working workflow" from user scripts. SoS is undoubtedly more readable in this domain because of its ability to include scripts largely verbatim. I am not claiming that this is better than CWL because it comes with its own disadvantages (e.g. lack of rigor in terms of workflow specification) but again, the goal is to make SoS usable in daily work.

We recently changed the license to require commercial license due to some other considerations (e.g. protection of the SoS format). I personally do not see it as a restriction though.