libSBML Python API
5.11.0
|
The libSBML “layout” extension implements support for the SBML Level 3 Layout package.
The layout of a reaction network diagram should be described as graphical representations of species and reactions (and not as arbitrary drawing or graph). This means that existing languages for the description of vector drawings (SVG) or general graphs cannot be used. While it may seem unnecessary to invent a new language when an existing one like SVG could in principle be used to describe the layout of a reaction network, there are good reasons to have a language tailored specifically for the layout of SBML models. Presumably, most programs that will use this SBML extension are primarily programs dealing with biochemical models. Internally, they will have data structures for species and reactions, so it will be natural for them to describe the layout of the reaction network also in terms of species and reactions (and not in terms of, e.g., polygons or splines). Thus, the LayoutClass object defined by this SBML Layout package has a similar structure like the SBML Model object and contains lists of graphical representations of compartments, species, and reactions. Additional layout elements and relationships can be represented by using other custom objects defined by this package.
Another important question is the level of detail that the description should provide. For simplicity, only the layout (i.e., the position of the different graphical objects) of the diagram is encoded, not the details of how it should be rendered; the latter is left to the SBML Level 3 Render package. The figure at right illustrates this distinction. All three diagrams could be renderings of the same layout and would be described by identical SBML files. No information about colors, line styles, fonts, etc., is present in the layout description.
The next question is how the relation between the model and the layout should be established. There seems to be a consensus that one model element can be represented by several layout elements. For example, it can be useful to have several representations of one species in the layout to avoid crossing lines. This can be accomplished if every layout element has a field that refers to the id of a model element.
There are also cases where a layout element does not correspondent to exactly one model element. One example is when a layout shows a simplified version of a model in which one reaction in the layout corresponds to several reactions and intermediate species in the model. This is the reason why the field in the layout elements that refers to the model elements is optional: to allow layout objects that do not have a specific counterpart in the SBML model.
The result of all this is a way to describe the graphical layout of a reaction network in biochemical terms. This layout can be closely tied to the model. A graphical editor, for example, would typically create a layout that is closely connected (by a one-to-several relation from the model elements to the layout elements) to the model. A more general layout design program could create a layout that is not so closely tied to the model; for example, it could create a layout that shows a simplified version of the model.
Historically, the SBML Layout package has been used to encode the layout
of SBML Level 2 models; indeed, the original version of the package was
developed in the context of SBML Level 2. The approach used with
Level 2 is to store the layout information as SBML annotations, i.e.,
using SBML <annotation>
elements. The following XML
namespace must be used for layout annotations in Level 2 models:
http://projects.eml.org/bcb/sbml/level2
A minimal example in this case would look like the following:
<?xml version="1.0" encoding="UTF-8"?> <sbml xmlns="http://www.sbml.org/sbml/level2" level="2" version="1"> <model> <annotation> <listOfLayouts xmlns="http://projects.eml.org/bcb/sbml/level2"> ... </listOfLayouts> </annotation> </model> </sbml>
Due to the way that the encoding difference discussed above affects legacy applications, libSBML implements special behavior for the Layout package: it always creates a Layout plugin object for any SBML Level 2 document it reads in, regardless of whether that document actually uses Layout constructs. This is unlike the case for SBML Level 3 documents that use Layout—for them, libSBML will not create a plugin object unless the document actually declares the use of the Layout package (via the usual Level 3 namespace declaration for Level 3 packages).
This has the following consequence. If an application queries for the presence of Layout in an SBML Level 2 document by testing only for the existence of the plugin object, it will always get a positive result; in other words, the presence of a Layout extension object is not an indication of whether a read-in Level 2 document does or does not use SBML Layout. Instead, callers have to query explicitly for the existence of layout information.
The special, always-available Level 2 Layout behavior was motivated by a desire to support legacy applications. In SBML Level 3, the Layout package uses the normal SBML Level 3 scheme of requiring declarations on the SBML document element. This means that upon reading a model, libSBML knows right away whether it contains layout information. In SBML Level 2, there is no top-level declaration because layout is stored as annotations in the body of the model. Detecting the presence of layout information when reading a Level 2 model requires parsing the annotations. For efficiency reasons, libSBML normally does not parse annotations automatically when reading a model. However, applications that predated the introduction of Level 3 Layout and the updated version of libSBML never had to do anything special to enable parsing layout; the facilities were always available for every Level 2 model as long as libSBML was compiled with Layout support. To avoid burdening developers of legacy applications with the need to modify their software, libSBML provides backward compatibility by always preloading the Layout package extension when reading Level 2 models. The same applies to the creation of Level 2 models: with the plugin-oriented libSBML, applications normally would have to take deliberate steps to activate package code, instantiate objects, manage namespaces, and so on. LibSBML again loads the Layout package plugin automatically when creating a Level 2 model, thereby making the APIs available to legacy applications without further work on their part.
This API documentation for libSBML does not provide a complete explanation of the SBML Level 3 Layout (“layout”) package. If you are developing software that uses “layout”, you are strongly urged to read the actual specification for the package. A link to the specification document current is provided below, along with a link to the page of known issues (if any).
Specification (in PDF format) | Known issues |
---|---|
![]() |
![]() |
The libSBML “layout” extension implements support for the SBML Level 3 Layout package.
The layout of a reaction network diagram should be described as graphical representations of species and reactions (and not as arbitrary drawing or graph). This means that existing languages for the description of vector drawings (SVG) or general graphs cannot be used. While it may seem unnecessary to invent a new language when an existing one like SVG could in principle be used to describe the layout of a reaction network, there are good reasons to have a language tailored specifically for the layout of SBML models. Presumably, most programs that will use this SBML extension are primarily programs dealing with biochemical models. Internally, they will have data structures for species and reactions, so it will be natural for them to describe the layout of the reaction network also in terms of species and reactions (and not in terms of, e.g., polygons or splines). Thus, the LayoutClass object defined by this SBML Layout package has a similar structure like the SBML Model object and contains lists of graphical representations of compartments, species, and reactions. Additional layout elements and relationships can be represented by using other custom objects defined by this package.
Another important question is the level of detail that the description should provide. For simplicity, only the layout (i.e., the position of the different graphical objects) of the diagram is encoded, not the details of how it should be rendered; the latter is left to the SBML Level 3 Render package. The figure at right illustrates this distinction. All three diagrams could be renderings of the same layout and would be described by identical SBML files. No information about colors, line styles, fonts, etc., is present in the layout description.
The next question is how the relation between the model and the layout should be established. There seems to be a consensus that one model element can be represented by several layout elements. For example, it can be useful to have several representations of one species in the layout to avoid crossing lines. This can be accomplished if every layout element has a field that refers to the id of a model element.
There are also cases where a layout element does not correspondent to exactly one model element. One example is when a layout shows a simplified version of a model in which one reaction in the layout corresponds to several reactions and intermediate species in the model. This is the reason why the field in the layout elements that refers to the model elements is optional: to allow layout objects that do not have a specific counterpart in the SBML model.
The result of all this is a way to describe the graphical layout of a reaction network in biochemical terms. This layout can be closely tied to the model. A graphical editor, for example, would typically create a layout that is closely connected (by a one-to-several relation from the model elements to the layout elements) to the model. A more general layout design program could create a layout that is not so closely tied to the model; for example, it could create a layout that shows a simplified version of the model.
Historically, the SBML Layout package has been used to encode the layout
of SBML Level 2 models; indeed, the original version of the package was
developed in the context of SBML Level 2. The approach used with
Level 2 is to store the layout information as SBML annotations, i.e.,
using SBML <annotation>
elements. The following XML
namespace must be used for layout annotations in Level 2 models:
http://projects.eml.org/bcb/sbml/level2
A minimal example in this case would look like the following:
<?xml version="1.0" encoding="UTF-8"?> <sbml xmlns="http://www.sbml.org/sbml/level2" level="2" version="1"> <model> <annotation> <listOfLayouts xmlns="http://projects.eml.org/bcb/sbml/level2"> ... </listOfLayouts> </annotation> </model> </sbml>
Due to the way that the encoding difference discussed above affects legacy applications, libSBML implements special behavior for the Layout package: it always creates a Layout plugin object for any SBML Level 2 document it reads in, regardless of whether that document actually uses Layout constructs. This is unlike the case for SBML Level 3 documents that use Layout—for them, libSBML will not create a plugin object unless the document actually declares the use of the Layout package (via the usual Level 3 namespace declaration for Level 3 packages).
This has the following consequence. If an application queries for the presence of Layout in an SBML Level 2 document by testing only for the existence of the plugin object, it will always get a positive result; in other words, the presence of a Layout extension object is not an indication of whether a read-in Level 2 document does or does not use SBML Layout. Instead, callers have to query explicitly for the existence of layout information.
The special, always-available Level 2 Layout behavior was motivated by a desire to support legacy applications. In SBML Level 3, the Layout package uses the normal SBML Level 3 scheme of requiring declarations on the SBML document element. This means that upon reading a model, libSBML knows right away whether it contains layout information. In SBML Level 2, there is no top-level declaration because layout is stored as annotations in the body of the model. Detecting the presence of layout information when reading a Level 2 model requires parsing the annotations. For efficiency reasons, libSBML normally does not parse annotations automatically when reading a model. However, applications that predated the introduction of Level 3 Layout and the updated version of libSBML never had to do anything special to enable parsing layout; the facilities were always available for every Level 2 model as long as libSBML was compiled with Layout support. To avoid burdening developers of legacy applications with the need to modify their software, libSBML provides backward compatibility by always preloading the Layout package extension when reading Level 2 models. The same applies to the creation of Level 2 models: with the plugin-oriented libSBML, applications normally would have to take deliberate steps to activate package code, instantiate objects, manage namespaces, and so on. LibSBML again loads the Layout package plugin automatically when creating a Level 2 model, thereby making the APIs available to legacy applications without further work on their part.
This API documentation for libSBML does not provide a complete explanation of the SBML Level 3 Layout (“layout”) package. If you are developing software that uses “layout”, you are strongly urged to read the actual specification for the package. A link to the specification document current is provided below, along with a link to the page of known issues (if any).
Specification (in PDF format) | Known issues |
---|---|
![]() |
![]() |
def libsbml.Point.__init__ | ( | self, | |
args | |||
) |
layout Representation of a point.
A point is specified via the required attributes 'x', 'y' and an optional attribute 'z', all of which are of type float. If the attribute z is not specified, the object is a two dimensional object. The Point class also has an optional attribute id of type SId. While not used in the “layout” package, it can be used by programs to refer to the elements.
This method has multiple variants; they differ in the arguments they accept.
__init__(long level, long version, long pkgVersion) Point __init__(long level, long version) Point __init__(long level) Point __init__() Point __init__(LayoutPkgNamespaces layoutns) Point __init__(Point orig) Point __init__(LayoutPkgNamespaces layoutns, float x, float y, float z=0.0) Point __init__(LayoutPkgNamespaces layoutns, float x, float y) Point __init__(XMLNode node, long l2version=4) Point __init__(XMLNode node) Point
Each variant is described separately below.
Creates a new Point from the given XMLNode
Point(Point orig)
Copy constructor.
Point(LayoutPkgNamespaces layoutns, float x, float y, float z =0.0)
Creates a new point with the given coordinates.
Point(long level = LayoutExtension.getDefaultLevel(), long version = LayoutExtension.getDefaultVersion(), long pkgVersion = LayoutExtension.getDefaultPackageVersion())
Creates a new point with x,y and z set to 0.0.
Point(LayoutPkgNamespaces layoutns)
Ctor.
def libsbml.Dimensions.__init__ | ( | self, | |
args | |||
) |
layout Spatial dimensions of a 2D or 3D shape.
A dimension is specified via the required attributes width, height and an optional attribute depth, all of which are of type float. If the attribute depth is not specified, the object is a two dimensional object. The width attribute of Dimensions specifies the size of the object in the direction of the positive x axis, the height attribute specifies the size of the object along the positive y axis and the depth attribute specifies the size of the object along the positive z axis. All sizes for Dimensions objects are positive values, and so the attributes are not allowed to take negative values. The Dimensions class also has an optional attribute id of type SId. While not used in the “layout” package, it can be used by programs to refer to the elements.
This method has multiple variants; they differ in the arguments they accept.
__init__(long level, long version, long pkgVersion) Dimensions __init__(long level, long version) Dimensions __init__(long level) Dimensions __init__() Dimensions __init__(LayoutPkgNamespaces layoutns) Dimensions __init__(Dimensions orig) Dimensions __init__(LayoutPkgNamespaces layoutns, float w, float h, float d=0.0) Dimensions __init__(LayoutPkgNamespaces layoutns, float w, float h) Dimensions __init__(XMLNode node, long l2version=4) Dimensions __init__(XMLNode node) Dimensions
Each variant is described separately below.
Dimensions(Dimensions orig)
Copy constructor.
Dimensions(XMLNode node, long l2version = 4)
Creates a new Dimensions object from the given XMLNode
Dimensions(LayoutPkgNamespaces layoutns, float w, float h, float d = 0.0)
Creates a new Dimensions object with the given sizes.
Dimensions(long level = LayoutExtension.getDefaultLevel(), long version = LayoutExtension.getDefaultVersion(), long pkgVersion = LayoutExtension.getDefaultPackageVersion())
Creates a new Dimensions object with the given level, version, and package version and with all sizes set to 0.0.
Dimensions(LayoutPkgNamespaces layoutns)
Creates a new Dimensions object with the given LayoutPkgNamespaces object.
def libsbml.BoundingBox.__init__ | ( | self, | |
args | |||
) |
layout A bounding box for an item in a diagram.
This method has multiple variants; they differ in the arguments they accept.
__init__(long level, long version, long pkgVersion) BoundingBox __init__(long level, long version) BoundingBox __init__(long level) BoundingBox __init__() BoundingBox __init__(LayoutPkgNamespaces layoutns) BoundingBox __init__(BoundingBox orig) BoundingBox __init__(LayoutPkgNamespaces layoutns, string id) BoundingBox __init__(LayoutPkgNamespaces layoutns, string id, float x, float y, float width, float height) BoundingBox __init__(LayoutPkgNamespaces layoutns, string id, float x, float y, float z, float width, float height, float depth) BoundingBox __init__(LayoutPkgNamespaces layoutns, string id, Point p, Dimensions d) BoundingBox __init__(XMLNode node, long l2version=4) BoundingBox __init__(XMLNode node) BoundingBox
Each variant is described separately below.
BoundingBox(BoundingBox orig)
Copy constructor.
BoundingBox(XMLNode node, long l2version=4)
Creates a new BoundingBox from the given XMLNode
(FOR BACKWARD COMPATIBILITY)
BoundingBox(LayoutPkgNamespaces layoutns, string id, float x, float y, float z, float width, float height, float depth)
Constructor which sets the id, the coordinates and the dimensions to the given 3D values.
(FOR BACKWARD COMPATIBILITY)
BoundingBox(long level = LayoutExtension.getDefaultLevel(), long version = LayoutExtension.getDefaultVersion(), long pkgVersion = LayoutExtension.getDefaultPackageVersion())
Default Constructor set position and dimensions to (0.0,0.0,0.0) and the id to an empty string.
BoundingBox(LayoutPkgNamespaces layoutns, string id, float x, float y, float width, float height)
Constructor which sets the id, the coordinates and the dimensions to the given 2D values.
(FOR BACKWARD COMPATIBILITY)
BoundingBox(LayoutPkgNamespaces layoutns, string id, Point p, Dimensions d)
Constructor which sets the id, the coordinates and the dimensions to the given values.
(FOR BACKWARD COMPATIBILITY)
BoundingBox(LayoutPkgNamespaces layoutns, string id)
Constructor set position and dimensions to (0.0,0.0,0.0) and the id to a copy of the given string.
(FOR BACKWARD COMPATIBILITY)
BoundingBox(LayoutPkgNamespaces layoutns)
Creates a new BoundingBox object with the given LayoutPkgNamespaces object.
def libsbml.GraphicalObject.__init__ | ( | self, | |
args | |||
) |
layout Base class of objects that store layouts.
All the more specific layout elements (CompartmentGlyph, GeneralGlyph, SpeciesGlyph, ReactionGlyph, ReferenceGlyph, TextGlyph, and SpeciesReferenceGlyph) are derived from the class GraphicalObject. Each object of class GraphicalObject has a mandatory BoundingBox, which specifies the position and the size of the object. While GraphicalObject is the base class for most elements in the “layout” package, it is not an abstract class. It can be instantiated when used in the listOfAdditionalGraphicalObjects to describe additional elements and relationships. Since it only describes a BoundingBox, programs are encouraged to add Annotation objects that describe program-specific graphical information.
This method has multiple variants; they differ in the arguments they accept.
__init__(long level, long version, long pkgVersion) GraphicalObject __init__(long level, long version) GraphicalObject __init__(long level) GraphicalObject __init__() GraphicalObject __init__(LayoutPkgNamespaces layoutns) GraphicalObject __init__(LayoutPkgNamespaces layoutns, string id) GraphicalObject __init__(LayoutPkgNamespaces layoutns, string id, float x, float y, float w, float h) GraphicalObject __init__(LayoutPkgNamespaces layoutns, string id, float x, float y, float z, float w, float h, float d) GraphicalObject __init__(LayoutPkgNamespaces layoutns, string id, Point p, Dimensions d) GraphicalObject __init__(LayoutPkgNamespaces layoutns, string id, BoundingBox bb) GraphicalObject __init__(XMLNode node, long l2version=4) GraphicalObject __init__(XMLNode node) GraphicalObject __init__(GraphicalObject source) GraphicalObject
Each variant is described separately below.
GraphicalObject(XMLNode node, long l2version=4)
Creates a new GraphicalObject from the given XMLNode
(FOR BACKWARD COMPATIBILITY)
GraphicalObject(GraphicalObject source)
Copy constructor.
GraphicalObject(LayoutPkgNamespaces layoutns, string id, Point p, Dimensions d)
Creates a new GraphicalObject with the given id
and 3D coordinates for the bounding box.
(FOR BACKWARD COMPATIBILITY)
GraphicalObject(long level = LayoutExtension.getDefaultLevel(), long version = LayoutExtension.getDefaultVersion(), long pkgVersion = LayoutExtension.getDefaultPackageVersion())
Creates a new GraphicalObject.
GraphicalObject(LayoutPkgNamespaces layoutns, string id, float x, float y, float z, float w, float h, float d)
Creates a new GraphicalObject with the given id
and 3D coordinates for the bounding box.
(FOR BACKWARD COMPATIBILITY)
GraphicalObject(LayoutPkgNamespaces layoutns, string id, BoundingBox bb)
Creates a new GraphicalObject with the given id
and 3D coordinates for the bounding box.
(FOR BACKWARD COMPATIBILITY)
GraphicalObject(LayoutPkgNamespaces layoutns)
Creates a new GraphicalObject with the given LayoutPkgNamespaces
GraphicalObject(LayoutPkgNamespaces layoutns, string id, float x, float y, float w, float h)
Creates a new GraphicalObject with the given id
and 2D coordinates for the bounding box.
(FOR BACKWARD COMPATIBILITY)
GraphicalObject(LayoutPkgNamespaces layoutns, string id)
Creates a new GraphicalObject with the given id
.
(FOR BACKWARD COMPATIBILITY)
def libsbml.CompartmentGlyph.__init__ | ( | self, | |
args | |||
) |
layout A glyph for an SBML compartment.
This method has multiple variants; they differ in the arguments they accept.
__init__(long level, long version, long pkgVersion) CompartmentGlyph __init__(long level, long version) CompartmentGlyph __init__(long level) CompartmentGlyph __init__() CompartmentGlyph __init__(LayoutPkgNamespaces layoutns) CompartmentGlyph __init__(LayoutPkgNamespaces layoutns, string id) CompartmentGlyph __init__(LayoutPkgNamespaces layoutns, string id, string compartmentId) CompartmentGlyph __init__(XMLNode node, long l2version=4) CompartmentGlyph __init__(XMLNode node) CompartmentGlyph __init__(CompartmentGlyph source) CompartmentGlyph
Each variant is described separately below.
CompartmentGlyph(CompartmentGlyph source)
Copy constructor.
CompartmentGlyph(long level = LayoutExtension.getDefaultLevel(), long version = LayoutExtension.getDefaultVersion(), long pkgVersion = LayoutExtension.getDefaultPackageVersion())
Default Constructor which creates a new CompartmentGlyph. Id and associated compartment id are unset.
CompartmentGlyph(LayoutPkgNamespaces layoutns)
Ctor.
CompartmentGlyph(XMLNode node, long l2version=4)
Creates a new CompartmentGlyph from the given XMLNode
(FOR BACKWARD COMPATIBILITY)
CompartmentGlyph(LayoutPkgNamespaces layoutns, string id, string compartmentId)
Constructor which creates a new CompartmentGlyph. Id and associated compartment id are set to copies of the values given as arguments.
(FOR BACKWARD COMPATIBILITY)
CompartmentGlyph(LayoutPkgNamespaces layoutns, string id)
Constructor which creates a new CompartmentGlyph with the given id
.
(FOR BACKWARD COMPATIBILITY)
def libsbml.LineSegment.__init__ | ( | self, | |
args | |||
) |
layout Representation of a line.
The LineSegment class consists of the mandatory attribute xsi:type and two child elements of type Point. One is called 'start' and represents the starting point of the line, the other is called 'end' and represents the endpoint of the line. The LineSegment class is also the base class for CubicBezier, which represent curved lines instead of straight ones.
This method has multiple variants; they differ in the arguments they accept.
__init__(long level, long version, long pkgVersion) LineSegment __init__(long level, long version) LineSegment __init__(long level) LineSegment __init__() LineSegment __init__(LayoutPkgNamespaces layoutns) LineSegment __init__(LayoutPkgNamespaces layoutns, float x1, float y1, float x2, float y2) LineSegment __init__(LineSegment orig) LineSegment __init__(LayoutPkgNamespaces layoutns, float x1, float y1, float z1, float x2, float y2, float z2) LineSegment __init__(LayoutPkgNamespaces layoutns, Point start, Point end) LineSegment __init__(XMLNode node, long l2version=4) LineSegment __init__(XMLNode node) LineSegment
Each variant is described separately below.
LineSegment(LayoutPkgNamespaces layoutns, Point start, Point end)
Creates a new line segment with the two given points.
LineSegment(long level = LayoutExtension.getDefaultLevel(), long version = LayoutExtension.getDefaultVersion(), long pkgVersion = LayoutExtension.getDefaultPackageVersion())
Creates a line segment with the given SBML level, version, and package version and both points set to (0.0,0.0,0.0)
LineSegment(LayoutPkgNamespaces layoutns, float x1, float y1, float z1, float x2, float y2, float z2)
Creates a new line segment with the given 3D coordinates.
LineSegment(LayoutPkgNamespaces layoutns, float x1, float y1, float x2, float y2)
Creates a new line segment with the given 2D coordinates.
LineSegment(XMLNode node, long l2version=4)
Creates a new LineSegment from the given XMLNode
LineSegment(LineSegment orig)
Copy constructor.
LineSegment(LayoutPkgNamespaces layoutns)
Creates a line segment with the LayoutPkgNamespaces and both points set to (0.0,0.0,0.0)
def libsbml.CubicBezier.__init__ | ( | self, | |
args | |||
) |
layout A Cubic Bézier smooth curve.
In order to be able to represent smooth curves the “layout” package defines the class CubicBezier. It represents a Bezier curve, and is readily available in most graphics APIs. The class CubicBezier is derived from LineSegment. It consists of four elements: the two inherited elements 'start' and 'end', which specify the starting point and the endpoint of the cubic bezier curve, and two elements 'basePoint1' and 'basePoint2', which specify the two additional base points that are needed to describe a cubic bezier curve.
This method has multiple variants; they differ in the arguments they accept.
__init__(long level, long version, long pkgVersion) CubicBezier __init__(long level, long version) CubicBezier __init__(long level) CubicBezier __init__() CubicBezier __init__(LayoutPkgNamespaces layoutns) CubicBezier __init__(LayoutPkgNamespaces layoutns, float x1, float y1, float x2, float y2) CubicBezier __init__(LayoutPkgNamespaces layoutns, float x1, float y1, float z1, float x2, float y2, float z2) CubicBezier __init__(CubicBezier orig) CubicBezier __init__(LayoutPkgNamespaces layoutns, Point start, Point end) CubicBezier __init__(LayoutPkgNamespaces layoutns, Point start, Point base1, Point base2, Point end) CubicBezier __init__(XMLNode node, long l2version=4) CubicBezier __init__(XMLNode node) CubicBezier
Each variant is described separately below.
CubicBezier(CubicBezier orig)
Copy constructor.
(FOR BACKWARD COMPATIBILITY)
CubicBezier(LayoutPkgNamespaces layoutns, Point start, Point end)
Creates a CubicBezier with the given points and returns the pointer.
(FOR BACKWARD COMPATIBILITY)
CubicBezier(long level = LayoutExtension.getDefaultLevel(), long version = LayoutExtension.getDefaultVersion(), long pkgVersion = LayoutExtension.getDefaultPackageVersion())
Creates a CubicBezier and returns the pointer.
CubicBezier(LayoutPkgNamespaces layoutns, float x1, float y1, float z1, float x2, float y2, float z2)
Creates a CubicBezier with the given 3D coordinates and returns the pointer.
(FOR BACKWARD COMPATIBILITY)
CubicBezier(LayoutPkgNamespaces layoutns, Point start, Point base1, Point base2, Point end)
Creates a CubicBezier with the given points and returns the pointer.
(FOR BACKWARD COMPATIBILITY)
CubicBezier(LayoutPkgNamespaces layoutns, float x1, float y1, float x2, float y2)
Creates a CubicBezier with the given 2D coordinates and returns the pointer.
(FOR BACKWARD COMPATIBILITY)
CubicBezier(XMLNode node, long l2version=4)
Creates a new Layout from the given XMLNode
(FOR BACKWARD COMPATIBILITY)
CubicBezier(LayoutPkgNamespaces layoutns)
Ctor.
def libsbml.Curve.__init__ | ( | self, | |
args | |||
) |
layout A curve connecting elements in a diagram.
The Curve class describes how to connect elements in a diagram defined with the use of the “layout” package. A curve is fully specified by a mandatory listOfCurveSegments element and is used in four places in the “layout” package:
In the text above, the term 'center piece' refers to either the Curve element of a ReactionGlyph, or its BoundingBox.
This method has multiple variants; they differ in the arguments they accept.
__init__(long level, long version, long pkgVersion) Curve __init__(long level, long version) Curve __init__(long level) Curve __init__() Curve __init__(LayoutPkgNamespaces layoutns) Curve __init__(XMLNode node, long l2version=4) Curve __init__(XMLNode node) Curve __init__(Curve source) Curve
Each variant is described separately below.
Curve(Curve source)
Copy constructor.
Creates a new Curve from the given XMLNode
Curve(long level = LayoutExtension.getDefaultLevel(), long version = LayoutExtension.getDefaultVersion(), long pkgVersion = LayoutExtension.getDefaultPackageVersion())
Creates a curve with an empty list of segments.
Curve(LayoutPkgNamespaces layoutns)
Creates a new Curve with the given LayoutPkgNamespaces object.
def libsbml.SpeciesReferenceGlyph.__init__ | ( | self, | |
args | |||
) |
layout A glyph for an SBML species reference.
The SpeciesReferenceGlyph element describes the graphical connection between a SpeciesGlyph and a ReactionGlyph (which would be an arrow or some curve in most cases). A SpeciesReferenceGlyph inherits from GraphicalObject, and adds a mandatory attribute 'speciesGlyph' and two optional attributes 'speciesReference' and 'role'. Optionally, the SpeciesReferenceGlyph also has a child element 'curve'.
If the curve is specified, it overrides the inherited bounding box.
This method has multiple variants; they differ in the arguments they accept.
__init__(long level, long version, long pkgVersion) SpeciesReferenceGlyph __init__(long level, long version) SpeciesReferenceGlyph __init__(long level) SpeciesReferenceGlyph __init__() SpeciesReferenceGlyph __init__(LayoutPkgNamespaces layoutns) SpeciesReferenceGlyph __init__(LayoutPkgNamespaces layoutns, string sid, string speciesGlyphId, string speciesReferenceId, long role) SpeciesReferenceGlyph __init__(XMLNode node, long l2version=4) SpeciesReferenceGlyph __init__(XMLNode node) SpeciesReferenceGlyph __init__(SpeciesReferenceGlyph source) SpeciesReferenceGlyph
Each variant is described separately below.
SpeciesReferenceGlyph(XMLNode node, long l2version=4)
Creates a new SpeciesReferenceGlyph from the given XMLNode
SpeciesReferenceGlyph(SpeciesReferenceGlyph source)
Copy constructor.
SpeciesReferenceGlyph(LayoutPkgNamespaces layoutns, string sid, string speciesGlyphId, string speciesReferenceId, long role)
Creates a new SpeciesReferenceGlyph. The id is given as the first argument, the id of the associated species glyph is given as the second argument. The third argument is the id of the associated species reference and the fourth argument is the role.
SpeciesReferenceGlyph(long level = LayoutExtension.getDefaultLevel(), long version = LayoutExtension.getDefaultVersion(), long pkgVersion = LayoutExtension.getDefaultPackageVersion())
Creates a new SpeciesReferenceGlyph with the given SBML level, version and package version. The id if the associated species reference and the id of the associated species glyph are set to the empty string. The role is set to SPECIES_ROLE_UNDEFINED.
SpeciesReferenceGlyph(LayoutPkgNamespaces layoutns)
Ctor.
def libsbml.ReferenceGlyph.__init__ | ( | self, | |
args | |||
) |
layout Connection between an object and a glyph.
The ReferenceGlyph element describes the graphical connection between an arbitrary GraphicalObject (or derived element) and a GeneralGlyph (which would be an arrow or some curve in most cases). A ReferenceGlyph inherits from GraphicalObject. Additionally it has a mandatory attribute 'glyph' and two optional attributes 'reference' and 'role'. Optionally, the ReferenceGlyph also has an element 'curve'. The ReferenceGlyph should either contain a bounding box or a curve specification. If both are given, the bounding box should be ignored.
This method has multiple variants; they differ in the arguments they accept.
__init__(long level, long version, long pkgVersion) ReferenceGlyph __init__(long level, long version) ReferenceGlyph __init__(long level) ReferenceGlyph __init__() ReferenceGlyph __init__(LayoutPkgNamespaces layoutns) ReferenceGlyph __init__(LayoutPkgNamespaces layoutns, string sid, string glyphId, string referenceId, string role) ReferenceGlyph __init__(XMLNode node, long l2version=4) ReferenceGlyph __init__(XMLNode node) ReferenceGlyph __init__(ReferenceGlyph source) ReferenceGlyph
Each variant is described separately below.
ReferenceGlyph(ReferenceGlyph source)
Copy constructor.
ReferenceGlyph(LayoutPkgNamespaces layoutns, string sid, string glyphId, string referenceId, string role)
Creates a new ReferenceGlyph. The id is given as the first argument, the id of the associated glyph is given as the second argument. The third argument is the id of the associated reference and the fourth argument is the role.
ReferenceGlyph(XMLNode node, long l2version=4)
Creates a new ReferenceGlyph from the given XMLNode
ReferenceGlyph(long level = LayoutExtension.getDefaultLevel(), long version = LayoutExtension.getDefaultVersion(), long pkgVersion = LayoutExtension.getDefaultPackageVersion())
Creates a new ReferenceGlyph with the given SBML level, version and package version. The id if the associated reference and the id of the associated glyph are set to the empty string. The role is set to empty.
ReferenceGlyph(LayoutPkgNamespaces layoutns)
Ctor.
def libsbml.GeneralGlyph.__init__ | ( | self, | |
args | |||
) |
layout A glyph for miscellaneous items.
The GeneralGlyph is used to facilitate the representation of elements other than Compartment, Species and Reaction and thus can be used for the display of relationships of Rule or elements defined by other SBML packages. It closely follows the structure of the ReactionGlyph. GeneralGlyph is defined to have an optional attribute reference as well as the elements curve, listOfReferenceGlyphs and listOfSubGlyphs.
This method has multiple variants; they differ in the arguments they accept.
__init__(long level, long version, long pkgVersion) GeneralGlyph __init__(long level, long version) GeneralGlyph __init__(long level) GeneralGlyph __init__() GeneralGlyph __init__(LayoutPkgNamespaces layoutns) GeneralGlyph __init__(LayoutPkgNamespaces layoutns, string id) GeneralGlyph __init__(LayoutPkgNamespaces layoutns, string id, string referenceId) GeneralGlyph __init__(XMLNode node, long l2version=4) GeneralGlyph __init__(XMLNode node) GeneralGlyph __init__(GeneralGlyph source) GeneralGlyph
Each variant is described separately below.
GeneralGlyph(GeneralGlyph source)
Copy constructor.
GeneralGlyph(long level = LayoutExtension.getDefaultLevel(), long version = LayoutExtension.getDefaultVersion(), long pkgVersion = LayoutExtension.getDefaultPackageVersion())
Creates a new GeneralGlyph. The list of reference glyph and subglyphs is empty and the id of the associated element is set to the empty string.
GeneralGlyph(LayoutPkgNamespaces layoutns, string id, string referenceId)
Creates a glyph with the given LayoutPkgNamespaces, id and set the id of the associated element to the second argument.
(FOR BACKWARD COMPATIBILITY)
GeneralGlyph(LayoutPkgNamespaces layoutns)
Creates a new GeneralGlyph with the given LayoutPkgNamespaces object.
GeneralGlyph(XMLNode node, long l2version = 4)
Creates a new GeneralGlyph from the given XMLNode
(FOR BACKWARD COMPATIBILITY)
GeneralGlyph(LayoutPkgNamespaces layoutns, string id)
Creates a glyph with the given LayoutPkgNamespaces and id.
(FOR BACKWARD COMPATIBILITY)
def libsbml.ReactionGlyph.__init__ | ( | self, | |
args | |||
) |
layout A glyph for an SBML reaction.
Analogous to how a Reaction object has to at least have one reactant or product, the ReactionGlyph has to at least have one SpeciesReferenceGlyph stored in the ListOfSpeciesReferenceGlyphs. Figure 12 on the following page provides the UML diagram for the class definition. The ReactionGlyph inherits from GraphicalObject. In addition to the attributes inherited from GraphicalObject, the ReactionGlyph is described by an attribute reaction, a Curve element and a listOfSpeciesReferenceGlyphs element. The Curve describes the center section of a ReactionGlyph. The center section is frequently used by tools to separate the point where substrates arcs come together, from the point where product arcs split off. The Curve is optional, and when not present the dimensions of the inherited BoundingBox describes the center section, by storing its position and dimension.
This method has multiple variants; they differ in the arguments they accept.
__init__(long level, long version, long pkgVersion) ReactionGlyph __init__(long level, long version) ReactionGlyph __init__(long level) ReactionGlyph __init__() ReactionGlyph __init__(LayoutPkgNamespaces layoutns) ReactionGlyph __init__(LayoutPkgNamespaces layoutns, string id) ReactionGlyph __init__(LayoutPkgNamespaces layoutns, string id, string reactionId) ReactionGlyph __init__(XMLNode node, long l2version=4) ReactionGlyph __init__(XMLNode node) ReactionGlyph __init__(ReactionGlyph source) ReactionGlyph
Each variant is described separately below.
ReactionGlyph(ReactionGlyph source)
Copy constructor.
ReactionGlyph(long level = LayoutExtension.getDefaultLevel(), long version = LayoutExtension.getDefaultVersion(), long pkgVersion = LayoutExtension.getDefaultPackageVersion())
Creates a new ReactionGlyph. The list of species reference glyph is empty and the id of the associated reaction is set to the empty string.
ReactionGlyph(LayoutPkgNamespaces layoutns, string id, string reactionId)
Creates a ResctionGlyph with the given LayoutPkgNamespaces, id and set the id of the associated reaction to the second argument.
(FOR BACKWARD COMPATIBILITY)
ReactionGlyph(LayoutPkgNamespaces layoutns)
Creates a new ReactionGlyph with the given LayoutPkgNamespaces object.
ReactionGlyph(XMLNode node, long l2version = 4)
Creates a new ReactionGlyph from the given XMLNode
(FOR BACKWARD COMPATIBILITY)
ReactionGlyph(LayoutPkgNamespaces layoutns, string id)
Creates a ResctionGlyph with the given LayoutPkgNamespaces and id.
(FOR BACKWARD COMPATIBILITY)
def libsbml.SpeciesGlyph.__init__ | ( | self, | |
args | |||
) |
layout A glyph for an SBML species.
In addition to the attributes it inherits from GraphicalObject, the SpeciesGlyph object has an optional 'species' attribute.
This method has multiple variants; they differ in the arguments they accept.
__init__(long level, long version, long pkgVersion) SpeciesGlyph __init__(long level, long version) SpeciesGlyph __init__(long level) SpeciesGlyph __init__() SpeciesGlyph __init__(LayoutPkgNamespaces layoutns) SpeciesGlyph __init__(LayoutPkgNamespaces layoutns, string id) SpeciesGlyph __init__(LayoutPkgNamespaces layoutns, string id, string speciesId) SpeciesGlyph __init__(XMLNode node, long l2version=4) SpeciesGlyph __init__(XMLNode node) SpeciesGlyph __init__(SpeciesGlyph source) SpeciesGlyph
Each variant is described separately below.
SpeciesGlyph(long level = LayoutExtension.getDefaultLevel(), long version = LayoutExtension.getDefaultVersion(), long pkgVersion = LayoutExtension.getDefaultPackageVersion())
Creates a new SpeciesGlyph with the given SBML level, version, and package version and the id of the associated species set to the empty string.
SpeciesGlyph(LayoutPkgNamespaces layoutns, string id, string speciesId)
Creates a new SpeciesGlyph with the given id
and the id of the associated species object set to the second argument.
(FOR BACKWARD COMPATIBILITY)
SpeciesGlyph(SpeciesGlyph source)
Copy constructor.
SpeciesGlyph(LayoutPkgNamespaces layoutns)
Ctor.
SpeciesGlyph(XMLNode node, long l2version=4)
Creates a new SpeciesGlyph from the given XMLNode
SpeciesGlyph(LayoutPkgNamespaces layoutns, string id)
Creates a new SpeciesGlyph with the given id
.
(FOR BACKWARD COMPATIBILITY)
def libsbml.TextGlyph.__init__ | ( | self, | |
args | |||
) |
layout A glyph for a text label.
The TextGlyph class describes the position and dimension of text labels in the “layout” package. It inherits from GraphicalObject and adds the attributes graphicalObject, text and originOfText.
This method has multiple variants; they differ in the arguments they accept.
__init__(long level, long version, long pkgVersion) TextGlyph __init__(long level, long version) TextGlyph __init__(long level) TextGlyph __init__() TextGlyph __init__(LayoutPkgNamespaces layoutns) TextGlyph __init__(LayoutPkgNamespaces layoutns, string id) TextGlyph __init__(LayoutPkgNamespaces layoutns, string id, string text) TextGlyph __init__(XMLNode node, long l2version=4) TextGlyph __init__(XMLNode node) TextGlyph __init__(TextGlyph source) TextGlyph
Each variant is described separately below.
TextGlyph(LayoutPkgNamespaces layoutns, string id, string text)
Creates a new TextGlyph. The id is given as the first argument, the text to be displayed as the second. All other attirbutes are set to the empty string.
(FOR BACKWARD COMPATIBILITY)
TextGlyph(TextGlyph source)
Copy constructor.
TextGlyph(long level = LayoutExtension.getDefaultLevel(), long version = LayoutExtension.getDefaultVersion(), long pkgVersion = LayoutExtension.getDefaultPackageVersion())
Creates a new TextGlyph with the given SBML level, versin and package version. The ids of the associated GraphicalObject and the originOfText are set to the empty string. The actual text is set to the empty string as well.
TextGlyph(LayoutPkgNamespaces layoutns)
Ctor.
Creates a new TextGlyph from the given XMLNode
(FOR BACKWARD COMPATIBILITY)
TextGlyph(LayoutPkgNamespaces layoutns, string id)
Creates a new TextGlyph. The id is given as the first argument.
(FOR BACKWARD COMPATIBILITY)
def libsbml.Layout.__init__ | ( | self, | |
args | |||
) |
layout The layout of a diagram of an SBML model.
The Layout class stores layout information for some or all elements of the SBML model as well as additional objects that need not be connected to the model. The Layout has two attributes: id and name. Additionally, a Dimensions element specifies the size of the layout. The actual layout elements are contained in several lists, namely: a ListOfCompartmentGlyphs, a ListOfSpeciesGlyphs, a ListOfReactionGlyphs, a ListOfTextGlyphs, and a ListOfAdditionalGraphicalObjects. Each of these lists can only occur once, and, if present, are not allowed to be empty.
This method has multiple variants; they differ in the arguments they accept.
__init__(long level, long version, long pkgVersion) Layout __init__(long level, long version) Layout __init__(long level) Layout __init__() Layout __init__(LayoutPkgNamespaces layoutns) Layout __init__(LayoutPkgNamespaces layoutns, string id, Dimensions dimensions) Layout __init__(XMLNode node, long l2version=4) Layout __init__(XMLNode node) Layout __init__(Layout source) Layout
Each variant is described separately below.
Layout(LayoutPkgNamespaces layoutns, string id, Dimensions dimensions)
Creates a new Layout with the given id
and dimensions.
(FOR BACKWARD COMPATIBILITY)
Layout(Layout source)
Copy constructor.
Creates a new Layout from the given XMLNode (only for SBML Level2)
(FOR BACKWARD COMPATIBILITY)
Layout(long level = LayoutExtension.getDefaultLevel(), long version = LayoutExtension.getDefaultVersion(), long pkgVersion = LayoutExtension.getDefaultPackageVersion())
Creates a new Layout with the given level, version, and package version.
Layout(LayoutPkgNamespaces layoutns)
Creates a new Layout with the given LayoutPkgNamespaces object.
def libsbml.LayoutModelPlugin.__init__ | ( | self, | |
args | |||
) |
This method has multiple variants; they differ in the arguments they accept.
__init__(string uri, string prefix, LayoutPkgNamespaces layoutns) LayoutModelPlugin __init__(LayoutModelPlugin orig) LayoutModelPlugin
Each variant is described separately below.
LayoutModelPlugin(LayoutModelPlugin orig)
Copy constructor. Creates a copy of this SBase object.
LayoutModelPlugin(stringuri, stringprefix, LayoutPkgNamespaces layoutns)
Constructor
def libsbml.LayoutSpeciesReferencePlugin.__init__ | ( | self, | |
args | |||
) |
layout Extension of SpeciesReference.
This method has multiple variants; they differ in the arguments they accept.
__init__(string uri, string prefix, LayoutPkgNamespaces layoutns) LayoutSpeciesReferencePlugin __init__(LayoutSpeciesReferencePlugin orig) LayoutSpeciesReferencePlugin
Each variant is described separately below.
LayoutSpeciesReferencePlugin(stringuri, stringprefix, LayoutPkgNamespaces layoutns)
Constructor
LayoutSpeciesReferencePlugin(LayoutSpeciesReferencePlugin orig)
Copy constructor. Creates a copy of this SBase object.
def libsbml.ListOfGraphicalObjects.clone | ( | self | ) |
layout A list of GraphicalObject objects.
The ListOfGraphicalObjects class in libSBML actually represents the ListOfAdditionalGraphicalObjects class in the “layout” package, and is a container for the additional GraphicalObject elements of a Layout.
The relationship between the lists and the rest of an SBML model is illustrated by the following (for SBML Level 2 Version 4):
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 means that software tools can add information about the lists themselves into each list container's 'annotation'.
Creates and returns a deep copy of this ListOfGraphicalObjects.
clone() ListOfGraphicalObjects
def libsbml.ListOfLineSegments.clone | ( | self | ) |
layout A list of LineSegment objects.
The ListOfLineSegments is a container for the LineSegment elements of a Curve.
The relationship between the lists and the rest of an SBML model is illustrated by the following (for SBML Level 2 Version 4):
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 means that software tools can add information about the lists themselves into each list container's 'annotation'.
Creates and returns a deep copy of this ListOfLineSegments.
clone() ListOfLineSegments
def libsbml.ListOfReferenceGlyphs.clone | ( | self | ) |
layout A list of ReferenceGlyph objects.
The ListOfReferenceGlyphs is a container for the ReferenceGlyph elements of a GeneralGlyph.
The relationship between the lists and the rest of an SBML model is illustrated by the following (for SBML Level 2 Version 4):
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 means that software tools can add information about the lists themselves into each list container's 'annotation'.
Creates and returns a deep copy of this ListOfReferenceGlyphs.
clone() ListOfReferenceGlyphs
def libsbml.ListOfSpeciesReferenceGlyphs.clone | ( | self | ) |
layout A list of SpeciesReferenceGlyph objects.
The ListOfSpeciesReferenceGlyphs is a container for the SpeciesReferenceGlyphs elements of a ReactionGlyph.
The relationship between the lists and the rest of an SBML model is illustrated by the following (for SBML Level 2 Version 4):
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 means that software tools can add information about the lists themselves into each list container's 'annotation'.
Creates and returns a deep copy of this ListOfSpeciesReferenceGlyphs.
clone() ListOfSpeciesReferenceGlyphs
def libsbml.ListOfCompartmentGlyphs.clone | ( | self | ) |
layout A list of CompartmentGlyph objects.
The ListOfCompartmentGlyphs is a container for the CompartmentGlyph elements of a Layout.
The relationship between the lists and the rest of an SBML model is illustrated by the following (for SBML Level 2 Version 4):
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 means that software tools can add information about the lists themselves into each list container's 'annotation'.
Creates and returns a deep copy of this ListOfCompartmentGlyphs.
clone() ListOfCompartmentGlyphs
def libsbml.ListOfSpeciesGlyphs.clone | ( | self | ) |
layout A list of SpeciesGlyph objects.
The ListOfSpeciesGlyphs is a container for the SpeciesGlyph elements of a Layout.
The relationship between the lists and the rest of an SBML model is illustrated by the following (for SBML Level 2 Version 4):
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 means that software tools can add information about the lists themselves into each list container's 'annotation'.
Creates and returns a deep copy of this ListOfSpeciesGlyphs.
clone() ListOfSpeciesGlyphs
def libsbml.ListOfReactionGlyphs.clone | ( | self | ) |
layout A list of ReactionGlyph objects.
The ListOfReactionGlyphs is a container for the ReactionGlyph elements of a Layout.
The relationship between the lists and the rest of an SBML model is illustrated by the following (for SBML Level 2 Version 4):
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 means that software tools can add information about the lists themselves into each list container's 'annotation'.
Creates and returns a deep copy of this ListOfReactionGlyphs.
clone() ListOfReactionGlyphs
def libsbml.ListOfTextGlyphs.clone | ( | self | ) |
layout A list of TextGlyph objects.
The ListOfTextGlyphs is a container for the TextGlyph elements of a Layout.
The relationship between the lists and the rest of an SBML model is illustrated by the following (for SBML Level 2 Version 4):
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 means that software tools can add information about the lists themselves into each list container's 'annotation'.
Creates and returns a deep copy of this ListOfTextGlyphs.
clone() ListOfTextGlyphs
def libsbml.ListOfLayouts.clone | ( | self | ) |
layout A list of Layout objects.
The ListOfLayouts is a container for the Layout elements of an extended Model element.
The relationship between the lists and the rest of an SBML model is illustrated by the following (for SBML Level 2 Version 4):
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 means that software tools can add information about the lists themselves into each list container's 'annotation'.
Creates and returns a deep copy of this ListOfLayouts.
clone() ListOfLayouts
def libsbml.LayoutExtension.getPackageName | ( | ) |
layout Base extension class for the package.
Returns the nickname of the SBML Level 3 package implemented by this libSBML extension.
getPackageName() string