Forums

Hi libSBML-users

During COMBINE the issue of no defaults in SBML and no defaults in
libSBML was raised (again!).

I appreciate that this has been discussed before, however, the views of
our customers are important to us. It is perhaps a good time to discuss
the matter again as we move forward to stabilising libsbml-5. So if you
have any thoughts please comment on the issue (outlined below).

Thanks

Sarah

==============

Currently libsbml 4.2.0 and 5.0.0 have constructors that take either a
level and version OR an SBMLNamespaces object as argument. Since SBML L3
does not define defaults the values of class attributes set by the
constructors is dependent on level/version.

So, for example:

Unit *u = new Unit(2, 4);

exp= u->getExponent()

will return a value of '1'
as in L2V4 the default value of the exponent attribute of a Unit is '1'
and so the constructor set the value.

BUT:

Unit *u = new Unit(3, 1);

exp= u->getExponent()

will return a value of 'NaN';
as in L3V1 the exponent attribute of a Unit has no default value
and thus the constructor did not set a value.

However, the exponent attribute of a Unit in L3V1 is a required
attribute and thus must have a value for the containing model to be
valid. Initially this meant that a user must construct an object and
then make sure all the required attributes were set with appropriate
values. To facilitate this, the init_defaults() functions; available on
each class of object; was adapted to assign values to all required
attributes based on the L2 default values regardless of what level the
object was actually using.

Thus:

Unit *u = new Unit(3, 1);
u->initDefaults();

will set values for the exponent, scale and multiplier attributes on the
newly created unit.

The issue raised at COMBINE was that this is an additional step that was
not necessary when using SBML L2 and therefore was an additional
complexity that needed to be considered when implementing support for L3.

There are a couple of options that would remove the need for *this*
additional step:

1) libSBML diverges from the SBML spec and DOES have default values for
attributes in L3

Advantage: constructors would just set the values and the user would
have no additional code requirement

Disadvantage: libSBML is supposed to reflect the spec and past
experience has shown that it causes problems for new users when it diverges.

2) Constructors could take an additional optional boolean flag that
indicates whether to set default values of not.

Advantage: user has control of how defaults are set

Disadvantage: users may have to include the additional flag - thus
changes to code may be needed

3) libSBML includes a global set-up that allows the user to specify
whether he wants to run 'with defaults' or 'without defaults'

Advantage: user has control and this 'state machine' concept could be
extended to other things like validity. (Note using libSBML-5 it will be
necessary to 'set-up' libsbml in order to tell it which packages you
wish to work with - runtime as well as build time).

Disadvantage: Additional step needed BUT only once. More care needed
when considering something that has a 'global' effect.


NOTE: This discussion is limited to code aimed at L3 models. We have no
intention of changing the functionality of code in relation to L2 models :-)

===============




____________________________________________________________
To manage your libsbml-development list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/libsbml-development

For a web interface to the libsbml-development mailing list, visit
http://sbml.org/Forums/

For questions or feedback about the libsbml-development list,
contact sbml-team@caltech.edu