Forums

Andreas Dräger wrote:
> Hi Nico and Marine,
>
> The forgotten files are now committed. Originally, I didn't intend to
> upload our reader/writer classes because we basically copy the libSBML
> objects into these in memory constructs. However, maybe this can be
> interesting for other people, too.
>
Yes, because the reader is existing and intensively tested.
We may want to replace it at some point (or not) by a call to a web
service that return the objects.
> Regarding Nico's comments: I agree. For the start of the project, I
> simply copied everything from SBMLsqueezer's repository. However, I
> think there is just the first line that we have to change in each header.
>
Not if we are going for LGPL :-)
And we need to choose the sentence to put as first line.
> The license of the trunk should be LGPL as Sara pointed out. For my
> branch I would like to stick with GPL. This shouldn't be a problem.
>
> One comment to the class Symbol: It is a convenient interface and the
> SBML specification states at some places that fields should be of type
> Variable or of type Symbol where Symbol means Variables that are allowed
> to be constant. To have a common superclass for Parameters, Species and
> Compartments is convenient for the following purposes:
> 1. We can create constructors that require an instance of Symbol and
> therefore ensure not to get some other NamedSBase or what ever.
> 2. We can group the many common features of Species, Compartments, and
> parameters, which is especially useful for applications that really use
> our jsbml as an internal data structure and that perform computation on in.
> But the problem is that the names of the arguments in SBML are sometimes
> a bit different for these three entities, e.g., the value or unit
> attribute in Species is called differently although it is basically the
> equivalent.
>
Yes, I know that, that is why I say we could keep it as an interface
that classes can implement.

My first reason was just to have the Species, Compartment, ... classes
closer to the UML which is a personal opinion.
But the second problem is that in SBML level 3 SpeciesReference can also
be a Symbol, I thought it had not constant or unit attribute but reading
again the core draft specs, it has a constant attribute and unit is
always dimensionless. Reaction can in a way also be consider as Symbol
as their id can be used in mathML
formula and the getValue() is less obvious in this case.
Depending of what will be adviced for the SBML level 3 packages
development, an interface might be easier to implement instead of having
to extends it.

Nico

____________________________________________________________
To manage your jsbml-development list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/jsbml-development

For a web interface to the jsbml-development mailing list, visit
http://sbml.org/Forums/

For questions or feedback about the jsbml-development list,
contact sbml-team@caltech.edu