Separate SED into several modules, breaking out a core that has a low barrier to entry

[jonrkarr]

As new features have been added, SED has grown more capable but also more complex to implement. This compels developers to implement more features, which increases the barrier to entry. This also creates a need to communicate to users which aspects of SED can be used with which tools.

A potential alternative is to organize SED-ML into a few namespaces/packages for distinct functions similar to the organization of SBML packages. One potential organization:

• Core: models, simulations, algorithms, algorithm parameters, basic tasks, reports
• Model changes
• Parameter estimation
• Repeated tasks
• Plotting
• Parallel execution -- see Create extension/package/namespace to capture information needed for parallel execution #157

A key goal would be to keep the core as simple as possible so there would be a minimal set of features that would be relatively easy for developers to implement. This could greatly reduce the barrier to entry.

[agarny]

This looks like a good way forward. (I know that, ideally, OpenCOR would support all of SED-ML, but time constraints, priorities, etc. have meant that it only supports a small subset of it, for now at least.)

[jonrkarr]

One benefit of modularizing SED-ML is that simulation tools really only need to implement simulations. The other functions could be conducted by external libraries and coupled to simulation tools. Simulation tools would only need to expose a few, fairly simple interfaces to make this work. As an example, this approach has enabled us to bring SED-ML to a bunch of additional tools without having to re-implement SED-ML for each tool.