I would like to bring an issue for specification developers. That will not
affect SBML support or usage. So everyone not concerned with spec writting,
you can leave :-)
At the moment, there is an abstract class in SBML definition, called Rule.
This class is a functional one (a semantic one), and is used to create the
concrete classes AssignmentRule, RateRule and AlgebraicRule.
At the same time, there are in the SBML core four classes with the same
syntax, that are used for a similar purpose:
Those construct share the same goal, to assign a value to something, or the
evolution of something. Although the attribute used to point to the
something varies, symbol or variable, the something is the same, that is a
species, a speciesReference, a compartment or a parameter.
The abstract classes are not seen by the end users, and are mostly
constructs used to reduce redundancy in the specification of the language.
Therefore, I think a good alternative to the current:
The effect is mild on the core, but propagate on the various packages.
For instance, writing the package multi, we're now multiplicating the
sections, UML diagrams and examples because the four assignments can affect
subpools (SpeciesTypeInstances) in addition of regular species.
(Whether we want to keep AlgebraicRule in SBML core is another story ...)
Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome-Trust
Genome Campus, Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/, @lenovere
To manage your sbml-discuss list subscription, visit
For a web interface to the sbml-discuss mailing list, visit
For questions or feedback about the sbml-discuss list,