SBML Level 3 package requirements draft
Guidelines for what SBML Level 3 packages can or can't do, and related issues.
- The reader of an SBML model must be able to ignore constructs in the namespace of a package used in the model, and the result should be a syntactically valid SBML model. This model may not give the expected mathematical results when being simulated, but it should be readable and manipulable to some extent.
- The model cannot refer to non-Core objects from within Core objects. For example, it cannot use an initial assignment to assign to the id of an object that is defined in a package being used in the model.
- MathML content within Core elements can't refer to things outside SBML Core constructs. For example,
cnelements inside the
mathof Core constructs can't reference identifiers of elements defined by package constructs. (However, the
mathof non-Core constructs can refer to id's of other non-core constructs.)
- Core attributes and elements should not have their existing semantics redefined or modified by packages.
- A package can't invalidate existing core constructs or change their semantics. For example, the package spec can't state that FunctionDefinition is redefined to allow any model identifiers to be used directly without passing them as parameters to the function. As another example, the package cannot redefine the standard Core KineticLaw construct to be usable for spatial rate laws simply by allowing references to identifiers in non-Core constructs. (The reason is that this would change the assumptions and meanings of the entities and processes, and thus change the interpretation of the KineticLaw numbers.)
- To extend the semantics of a core construct (such as spatial versions of a kineticlaw), they must be put in separate namespace-qualified constructs
- A package can build on another package, and extend it. The rules (1) and (2) only apply to Core constructs, so violations of these rules in non-core constructs is not prohibited.
- A package definition should follow the principle of no default values for attributes that is followed in SBML Level 3 Core.
- Note that this is not the same as inheritance. Attributes can be optional with no default values, and a specification can define how a missing value is taken from another attribute elsewhere in the model, in the same way that the Model attributes for units in Level 3 Core provide values that can be inherited by other SBML constructs.
- A package definition cannot redefine the MathML subset permitted in Core constructs. Instead, to extend the mathematical constructs, it a package can extend FunctionDefinition by (e.g.) adding a reference to a controlled vocabulary of externally-specified functions. This allows a model to define a default result returned by the FunctionDefinition when the package is ignored, satisfying guideline (1), and it avoids the need for a package to redefine the MathML subset.