Forums

Hmm, not a lot of responses...

I'm going to agree with Frank that I think the most pragmatic approach is
for libSBML to provide defaults. I think the benefit of the 'no defaults'
approach to the specification is that the produced document itself needs
to be explicit so it can be interpreted correctly. I *don't* think that
the benefit of 'no defaults' should extend to a claim that 'the modeler
has actually thought about everything'. If documents like:

<unit kind="mole" exponent="NaN" scale="2147483647" multiplier="NaN"/>

start getting traded around, I actually think the benefit of the 'no
defaults' approach has been *lost* because now the interpreter must parse
'NaN' and make some decision about what to do (if indeed it doesn't simply
crash). If 'multiplier="NaN"' is valid SBML, why is 'multiplier' a
required value in the first place? Why not just leave it off and tell the
interpreter, "Well, you're on your own here; I have no idea."

(Actually, can I propose an extension to the core spec that 'NaN' is
an invalid value for SBML doubles? I can't see that ever being helpful.)

I think libSBML should instead produce valid *readable* SBML, and that
means providing defaults.

Now, if you want to provide tools for users who want to make sure SBML
didn't set any defaults, I might add this to the validation 'Warnings'
list. Let the user create a model, keep track of what was set and what
wasn't set, let the 'isSetX' functions respond appropriately, and when
validated, check them, with, perhaps, a new SBMLErrorCategory enum:

LIBSBML_CAT_LIBSBML_DEFAULTS Category of warnings about values that
have been provided by libSBML and not the creator of the model. This
particular category applies only to models as they are being
manipulated by libSBML; once they are written out, that information is
lost.

(Although I dunno, you could annotate things saying 'this is a
libSBML-provided default value' if you really wanted to. I'm not sure
what benefit this would provide, however.)

-Lucian


* Sarah Keating <skeating@caltech.edu> [2009-09-15 11:44] writes:
> Hi libSBML-users
>
> NOTE: Feedback requested :-)
>
> For anyone interested the current svn trunk for libSBML now contains
> code that sets any new attributes (with the exception of sbml:units and
> the required attribute for packages) and writes out SBML L3.
>
> We will release this as a beta but we have one outstanding issue that we
> would appreciate your feedback on:
>
> ================
>
> The SBML Level 3 specification removes default values. Thus it will be
> the responsibility of the user to set values for any required
> attributes. For example the following code
>
> Unit * u = new Unit(3,1);
> u->setKind("mole")
>
> would create a unit that would have the following values:
>
> <unit kind="mole" exponent="NaN" scale="2147483647" multiplier="NaN"/>
>
> This would be the internal representation of the unit.
>
> Using the function getMultiplier() will return NaN etc.
>
> Writing out this unit would produce the text above; since the attributes
> are now required libSBML will write them out with their current value -
> which have obviously not been set.
>
> This leaves libSBML in a slight dilemma regarding boolean attributes.
> There is no such thing as "Not-A-Boolean". Thus any boolean attribute
> must be internally initialised with a boolean value. So for example
>
> Species * s = new Species(3,1);
>
> would produce a species
>
> <species id="" compartment="" hasOnlySubstanceUnits="false"
> boundaryCondition="false" constant="false"/>
>
> where the boolean attributes have values (the default L2 values) even
> though the user has not explicitly set them.
>
> So using the function getBoundaryCondition() will return "false".
>
> Obviously we can use internal flags to track whether an attribute has
> been explicitly set and the function isSetBoundaryCondition() would
> return "false"; but can we rely on the user to check :-) ?
>
> We have a thought on this, but appreciate it is not the neatest of
> solutions:
>
> The getBooleanFoo() functions could check whether the attribute has been
> set and throw an exception if it has not.
>
> The write process could also check and produce something like
>
> <species id="" compartment="" hasOnlySubstanceUnits="Not Set"
> boundaryCondition="Not Set" constant="Not Set"/>
>
> Our reasoning is that this will avoid a user receiving bad information
> regarding a model.
>
> We would appreciate your thoughts on this.
>
> Please keep in mind that whilst the above discussion uses attributes we
> are already all familiar with - L3 + packages may well introduce other
> boolean attributes where there is no obvious default value!!
>
> Thanks
>
> Sarah
>
>
>
>
> ____________________________________________________________
> 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
>
____________________________________________________________
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