Forums

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