The various ListOf___ structures in SBML are merely containers used for organizing the main components of an SBML model. In libSBML's implementation, ListOf___ data structures are derived from the intermediate utility structure ListOf_t, which is not defined by the SBML specifications but serves as a useful programmatic construct. ListOf_t is itself is in turn derived from SBase_t, which provides all of the various ListOf___ data structures with common features defined by the SBML specification, such as "metaid" attributes and annotations.
The relationship between the lists and the rest of an SBML model is illustrated by the following (for SBML Level 2 Version 4):
SBML Level 3 Version 1 has essentially the same structure as Level 2 Version 4, depicted above, but SBML Level 3 Version 2 allows containers to contain zero or more of the relevant object, instead of requiring at least one. As such, libsbml will write out an otherwise-empty ListOf___ element that has any optional attribute set (such as 'id' or 'metaid'), that has an optional child (such as a 'notes' or 'annotation'), or that has attributes or children set from any SBML Level 3 package, whether or not the ListOf___ has any other children.
Readers may wonder about the motivations for using the ListOf___ containers in SBML. A simpler approach in XML might be to place the components all directly at the top level of the model definition. The choice made in SBML is to group them within XML elements named after ListOfClassname, in part because it helps organize the components. More importantly, the fact that the container classes are derived from SBase_t means that software tools can add information about the lists themselves into each list container's "annotation".
In the C API for libSBML, functions that in other language APIs would be inherited by the various ListOf___ structures not shown in the pages for the individual ListOf___'s. Instead, the functions are defined on ListOf_t. Please consult the documentation for ListOf_t for the many common functions available for manipulating ListOf___ structures. The documentation for the individual ListOf___ structures (ListOfCompartments_t, ListOfReactions_t, etc.) does not reveal all of the functionality available.
The pointer that is returned by this function is not owned by the caller, but may be queried and modified. Any changes made will be reflected in any resulting SBML document containing the pointer's parent.
an unsigned int representing the index of the Submodel_t to retrieve.
Returns
the nth Submodel_t in this ListOf_t. If the index n is invalid, NULL is returned.
Note
The pointer that is returned by this function is not owned by the caller, but may be queried and modified. Any changes made will be reflected in any resulting SBML document containing the pointer's parent.
The pointer that is returned by this function is owned by the caller, who is responsible for deleting it. Any changes made to the element will not be reflected in any resulting SBML document unless the element is added to an SBML Document. Even in this case, the element's deletion is still the responsibility of the caller with two exceptions: if it is used as the "disownedItem" in the ListOf_appendAndOwn() or ListOf_insertAndOwn() functions. All other functions in libsbml add a copy of the element, and do not transfer ownership of the pointer.
The pointer that is returned by this function is owned by the caller, who is responsible for deleting it. Any changes made to the element will not be reflected in any resulting SBML document unless the element is added to an SBML Document. Even in this case, the element's deletion is still the responsibility of the caller with two exceptions: if it is used as the "disownedItem" in the ListOf_appendAndOwn() or ListOf_insertAndOwn() functions. All other functions in libsbml add a copy of the element, and do not transfer ownership of the pointer.
Visit SBML.org for more information
about SBML and libSBML.
