General principles for Level 3 design
The rest of this page describes general principles being followed in the design of Level 3 Core. These principles arose from discussions in the SBML community at various times, together with additional considerations developed by the SBML Editors in the process of working on SBML Level 3.
Other pages describe specific changes planned for SBML Level 3.
Level 3 Core will not be a complete redesign of SBML
Many aspects of SBML are, frankly, not pretty. As tends to happen with formats and other computer artifacts that evolved over time, the structure of SBML and many specific details are not ideal or done in a way that one might do if given the opportunity to redesign SBML with 20-20 hindsight. Despite this, it is currently the consensus among heavy SBML users that it is not so bad that it is needs a ground-up redesign. Large changes to SBML would require large changes in supporting software, and the bottom line is that no one feels it is worth the time, effort and resources to go that far. Consequently, Level 3 Core will be highly similar to Level 2 Version 4.
Level 3 Core will not contain unnecessary changes
Given the opportunity of creating a whole new Level of SBML, there is a temptation to make small changes just because we can (e.g., to remove some long-standing wart). As a general principle of Level 3 development, the SBML Editors feel it is better to restrain from making changes that do not represent either (1) technical fixes, (2) changes necessary for supporting Level 3 packages, or (3) changes that reduce opportunities for errors in interpreting SBML.
The form of SBML's definition will remain the same
The form of the definition of the XML (specifically, whether an XML Schema is provided, or whether other technology such as RELAX NG is used) is a technicality that needs to be resolved, but is not the main problem in defining SBML. The definition of SBML components and use should remain at the level of object structures (using UML notation) and associated textual descriptions.
No MathML additions in the Core
In the past, there have been proposals to extend the subset of MathML supported in SBML, for example by the addition of MathML's
<vector>. Level 3 represents an obvious opportunity to revisit the topic of adding more MathML constructs.
After briefly considering the idea of adding new MathML constructs in anticipation of their need by Level 3 packages, and careful consideration of the implications, the SBML Editors decided against doing so. Instead, each Level 3 package will define whatever additional MathML constructs it needs on a case-by-case basis. The rationale for this design principle is the following:
- It is impossible to predict which constructs will be needed by future Level 3 packages; therefore, attempts to add MathML constructs in anticipation of future needs is doomed to failure.
- Adding MathML constructs to the Core, if they cannot properly be used except via some Level 3 package, would be asking for trouble. People would inevitably attempt to use them anyway.
- Additions of MathML constructs to the Core would further distance the Core from Level 2 Version 4, going against the goal of making the Level 2 to Level 3 Core transition as straightforward as possible.