Parentage of objects in libSBML
21 May '08 14:16
This is a proposal for an addition within libSBML and I would be
grateful for any observations people may have; positive or negative :-)
Currently all objects representing SBML components are derived from the
SBase class and contain a pointer to the document object within which
they are contained. The objects all have functions 'setSBMLDocument' and
'getSBMLDocument'. Thus it is possible for any object to access the
model of which it is a part using getSBMLDocument()->getModel().
This is fine with the current SBML specification that states that there
can only be one model per document. However this is likely to change in
Level 3; ie there may be multiple models within a single SBMLDocument.
To facilitate this we propose that each object will contain an
additional pointer to it's direct parent object.
NOTE: setSBMLDocument and getSBMLDocument will NOT change
Initially we had considered that this additional pointer would reference
the parent *model* of the object; thus in a situation with multiple
models within one document each object could still reference its parent
However, since the unit consistency checking makes heavy use of this
functionality, it occurred to me that any object should be able to
access its direct parent e.g. a KineticLaw should know which Reaction it
is in. There are some ugly hacks in the unit checking code that
communicate this information :-) Thus if every object was able to
reference its direct parent it could still access the whole model if
necessary, but the additional information may prove to be useful.
I also thought that making this information available to an ASTNode
might also be useful; thus any math element would know where it came
from - I can see this being useful if you want to determine undeclared
units from expressions!
So, in summary, all SBase objects would reference their direct SBase
parent and all ASTNodes would reference their parent SBase object. So
there would be a hierarchy of references:
I reiterate the current code whereby any object can reference its parent
SBMLDocument would not change - so we shouldnt break anything :-)
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,
Powered by FUDforum. (Copyright Advanced Internet Designs Inc.)