Re: No defaults in SBML L3
21 Sep '09 12:56
* Stefan Hoops <email@example.com> [2009-09-21 20:21] writes:
> Hello Chris,
> On Mon, 21 Sep 2009 11:39:46 -0600
> "Chris J. Myers" <firstname.lastname@example.org> wrote:
> > A better approach, in my opinion, is to come up with ways that
> > people can use L3 for their needs. Case in point is my suggestion of
> > adding a readSBML that provides defaults to required entries. Or, a
> > readAndConvert function which would also need to provide defaults
> > since L2 had defaults. I really think it is problematic to allow
> > SBML files to be read that have missing, unspecified, required
> > entries.
> I agree again. However, I do not advocate to introduce the fix
> functions you suggest. An L3 file which does not contain mandatory
> elements is not valid and can not be fixed.
Let's be clear: libSBML has always and will always have the ability to
read invalid SBML. It *must* be able to do this if it is going to
help tools fix broken SBML. It reads it and sets an error. That's not
what's under discussion here.
Similarly, libSBML has always and (as far as I can tell) will always have
the ability to *write* invalid SBML. There's no getting around it,
especially when you're trying to debug stuff. Again, it sets an error and
writes it anyway. This is also not what's under discussion.
The question is instead: "When libSBML is asked to write an invalid file,
should it try to fix it by providing defaults?" This isn't about L2 vs.
L3 or anything like that. It's about how to make the best of an
unfortunate situation. I think it should write defaults, and would at
least appreciate the ability to ask it to write defaults. In the end,
this is the option that results in the fewest number of invalid SBML files
in the wild.
To manage your libsbml-development list subscription, visit
For a web interface to the libsbml-development mailing list, visit
For questions or feedback about the libsbml-development list,