Forums

* Stefan Hoops <shoops@vbi.vt.edu> [2009-09-21 18:23] writes:
>
> I completely understand that the programmers coding towards L3 want to
> have as little differences as possible between the code towards L2 and
> L3.

I am pretty sure this is not the issue. The issue is more whether people
see and use libSBML as a tool or as an extension of the spec (or something
in the middle). Clearly, a tool can and should fill in defaults as it
sees fit. And equally clearly, we have decided as a community to not have
defaults in the spec. Where will libSBML fall on that spectrum?

> However the decision to remove defaults in L3 is based on the
> problems people have with not knowing what values are optional and
> which of the optional values have defaults and if so which.

Surely the answer here would be "look at the file that libSBML produced,
and see what it wrote out--anything you didn't specify but that shows up
is something required by L3, and libSBML's defaults are what it wrote."

Also, that is not the only reason behind the switch to no defaults. The
main reason I was familiar with was that interpreters could not read an
SBML file and be guaranteed to know all aspects of the model--they must
instead know both the file and the place in the spec where the default was
defined. If there are no defaults, the interpreter can be assured that as
long as the file is valid, all the information needed to parse the file is
present in the file, and nowhere else.

This would still be achieved if libSBML wrote out defaults, because the
produced files would be easily exchanged between other readers.

That aside, I can see several options for what libSBML does when asked to
write a file with unset required elements. The first is my least
favorite: to write out a file that pretends to be valid SBML but is
actually uninterpretable:

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

What's an interpreter supposed to do with this? All the elements are
there, so it seems like it's valid, but in actual fact, it is impossible
to construct a model from the values provided. Thus, the tool cannot rely
on a schema to tell it if the file is valid SBML or not, but must instead
parse the values before it knows.

Better, to my mind, would be if libSBML wrote out invalid SBML:

<unit kind="mole" />

Under this option, everyone knows the file is invalid from the get-go, and
the interpreter or parsing tool (even libSBML again) can report the error
to the user or do whatever else it wants to do.

The problem here (to my mind) is that there's less feedback than there
could be. The user might check the error list in libSBML, but if they
just write out the file and continue on, they'll never be told that there
was a required element they never defined.

Which is one reason why I would advocate at least the ability in libSBML
to write out valid SBML if all that's otherwise missing is defaults:

<unit kind="mole" exponent="1" scale="0" multiplier="1" />

The other reason I would advocate this is that one of the design goals of
libSBML4+ is to facilitate the creation of valid SBML files, and make it
harder to create invalid SBML files. Providing defaults like this does
both.

If you wanted to try to teach people not to use libSBML's defaults, you
could use annotation to convey this:

<unit kind="mole" exponent="1" scale="0" multiplier="1" />
<!-- Note: values for elements 'exponent', 'scale', and 'multiplier'
were provided by libSBML and not by the user. To prevent this
message from appearing, these elements need to be set explicitly -->

(pretend '<!-- -->' is valid SBML for the purposes of this suggestion.)

Finally, libSBML could refuse to write out the file at all. This would be
a major change in the API, and would probably make lots of people unhappy,
though. At the very least, writing out invalid SBML is invaluable when
debugging.

Now, there are several options here, some of which may make most people
happy:

Different 'writeSBML' functions:

writeSBML() <- only writes valid SBML files.
writeSBMLWithDefaults() <- only writes valid SBML files, but if the only
thing wrong is the lack of defaults, it
provides them.
writeInvalidSBML() <- writes what it has, invalid or not (this is
what 'writeSBML' does currently)
writeInvalidSBMLWithDefaults() <- writes what it has, invalid or not, but
provides defaults if need be.

(you could also accomplish the above with flags instead of having
different function names; 'writeSBML(invalid=false, defaults=true)', say.)

You could also set functions that did the above for everything at once:

setUseDefaults(bool);
setWriteInvalidSBML(bool);

These could either be global or model-specific functions.

Providing these options would make for more coding on the part of
libSBML's developers, of course. There are, after all, only so many hours
in the day, and there are perhaps more important things they could spend
their time coding (like Hierarchical Modeling support ;-)


Finally, to answer Stefan's questions:

> Just some problems I see:
> 1) Who defines what the defaults are?

libSBML.

> 2) What values have defaults?

Anything SBML requires. (Or, well, maybe not *everything* but a lot of
things.)

> 3) Where is this documented?

In the libSBML documentation.


-Lucian
____________________________________________________________
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