Forums

Thanks for the responses.

In my previous life writing code for microprocessors my customers would
have been extremely unhappy if the code did not exactly reflect the
specification - it seems libSBML customers are a different breed :-)

Lucian's idea of including a check on whether values have been set as
part of validation is good - and we shall certainly implement that. We
just have to hope people validate SBML they have created before they
output it.

Clearly no defaults in libSBML is not particularly popular. I
acknowledge that in many cases libSBML using the default value from L2
would not cause any real issues. The biggest exception is
spatialDimensions !

If spatialDimensions defaults to a number then this is making implicit
an statement about the compartment units that is open to misinterpretation.

Consider the following code:

============
Compartment *c = new Compartment(3,1);

c->setUnits("metre");
=============

Since the user has made no explicit declaration about the
spatialDimensions, if the spatialDimensions defaults to 3, this creates
an invalid internal representation of a compartment - something
libSBML-4 tries very very hard to avoid doing blindly.

Also consider this code:

===============
Model *m = new Model(3,1);
m->setVolumeUnits("whatever");

Compartment *c = m->createCompartment();
===============

Again, implicitly compartment c has units of "whatever" - since by
default the spatialDimensions are 3.

SBML Level 3 core removed defaults so that these sorts of implicit
declarations were removed !!

Sarah

******************

In response to Chris' comment that libSBML is basically a tool. I
actually disagree with this. libSBML is a parser that adds functionality
for conversion and validation BUT is primarily a library for
reading/writing/creating SBML. It does not need to have any
comprehension of the concepts and how the relate to each other or to any
other concept. It must NEVER make assumptions about what a user
intended. IMHO those are the facilities provided by the tools that use
libSBML :-)



Chris J. Myers wrote:
> I agree as well. The no defaults should apply only to the model file
> and not libsbml. Tools should be allowed to have defaults to make
> life easier on users and libsbml is basically a tool.
>
> Chris
>
> Sent from my iPod
>
> On Sep 18, 2009, at 6:03 PM, Lucian Smith <lpsmith@spod-central.org>
> wrote:
>
>> 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
> ____________________________________________________________
> 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