Re: [jsbml-development] jsbml/parsing errors
31 Mar '11 02:45
to me this is a no brainer: keep the attribute if it was originally there.
On Thursday 31 March 2011 10:05:38 Andreas Draeger wrote:
> Dear all,
> There is currently a discussion going on in the JSBML mailing list that
> requires the opinion of some people from the SBML community.
> The question is:
> Should we or should we not keep the information constant=true in local
> parameters with SBML Level < 3 when writing an SBML file given that this
> was written in an original file?
> >>> One question is, do we want to write back the constant attribute to
> >>> keep the file as it was ?? If yes, we probably need to add a class
> >>> attribute to tell us if the constantAttribute was set and then add it
> >>> in the writeAttribute method.
> >> It does not really make sense to write "constant=true" in a local
> >> parameter with Level < 3, because by default this is always the case. No
> >> matter what was written in an original file, I would remove this in any
> >> case.
> > There is nothing wrong to put the attribute to true, like this, you are
> > sure that other software that use your SBML file
> > will set the attribute to true even if they do not know the default
> > value that is written in the SBML specs.
> > But also, it is nice to give back the model as it was written by the
> > user or the tool that created it. This is why we are doing that for all
> > the other
> > attributes in all the other classes that have a default value in the
> > specs. If the user set it in the original file, we are writing it back
> > even if it is the default value.
> > Not sure why we should make an exception for the constant attribute in
> > the class parameter.
Chair in Computational Systems Biology
School of Computer Science
Manchester Centre for Integrative Systems Biology
University of Manchester
Manchester Interdisciplinary Biocentre
131 Princess Street
Manchester, M1 7DN, U.K.
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,
Powered by FUDforum. (Copyright Advanced Internet Designs Inc.)