Allow more data type flexibility with UniformRange, VectorRange and other classes for logical and other modeling formalisms

[jonrkarr]

Many of the SED-ML classes presume that models and simulation experiments involve float-value attributes.

• UniformTimeCourse.initialTime, UniformTimeCourse.outputStartTime, UniformTimeCourse.outputEndTime
• OneStep.step
• UniformRange.start, UniformRange.end
• VectorRange.values
• Parameter.value

This makes it difficult to use SED-ML (as strictly typed) for other types of simulations beyond continuous simulations.

Examples

• The initial conditions of discrete simulations are integer-valued. Strictly speaking, this is incompatible with UniformRange or VectorRange. The float type of UniformRange and VectorRange also makes it difficult to use FunctionalRange with integer-valued simulations.
• Similarly, the initial conditions of Boolean simulations are Boolean-valued. Strictly speaking, this is incompatible with UniformRange or VectorRange.
• Logical simulations typically have integer-valued time courses. Strictly speaking, this isn't compatible with UniformTimeCourse.

The lack of type flexibility leads other domains to think that additional SED classes need to be added (e.g., proposal linked in #8). Supporting other modeling formalisms with extensions of SED that add new classes would increase the complexity of SED (and libSED-ML) and likely lead to further splintering (and inconsistency) in software support for SED. This would detract from the goals of reproducibility and portability.

Of course, software tools could simply type cast the values of SED attributes. From this perspective, SED and libSED-ML can be already be used with other modeling formalisms. Nevertheless, the reliance on float-valued attributes in the specifications discourages modelers from other domains from using SED. To avoid discouraging other domains, its important to communicate to other modeling domains that SED is relevant and avoid statements that might make modelers in other domains think otherwise.

Other modeling formalisms could be supported without additional classes, simply by making the data types of the attributes of several classes more flexible.

• Support integers
  • UniformTimeCourse.initialTime, UniformTimeCourse.outputStartTime, UniformTimeCourse.outputEndTime
  • OneStep.step
  • UniformRange.start, UniformRange.end
• Support integers, Booleans, and strings (e.g., for enumerations)
  • VectorRange.values
• Add note to documentation that math for ComputeChange, SetValue, and FunctionalRange (Calculation in L1V4) can also produce integer or Boolean values.

[luciansmith]

I labeled this L2 because I can see the utility of an additional optional 'type' attribute for these elements.

However, there's nothing stopping anyone from restricting any double in L1v4 to be an integer or a Boolean already if they want. I have a hard time imagining the mindset of anyone being discouraged from using SED-ML because it supports floats but not (somehow) integers or Booleans. Surely you can store integers and Booleans as floats; it's a non-lossy conversion. There could be additional libsedml support for this if we wanted (by adding '...asInteger' or 'asBoolean' to the various 'getX' functions, i.e. 'getValueAsInteger'. But I don't see it as a spec issue for L1v4.