— the global portal for all things SBML



The existing API



  • a level and version that are the target of the change you want to make
  • a strict flag to convey that you only wish to deal with valid to valid conversion (both your input and the resulting model must be valid SBML according to the validators you have selected)

does the following

1. if strict

  • runs validation
    • if it fails exits with
      • conversion success = false
      • existing model unchanged

if not strict skip this

2. runs compatibility validation based on current model and the target level/version

  • if no information or only semantic information is lost
    • does conversion
    • logs warnings about lost info
  • if mathematical information would be lost
    • exits with
      • conversion success = false
      • existing model unchanged

at this point conversion has happened or we have exited

3. if strict

  • validate result
    • if fails exits with
      • conversion success = false
      • existing model unchanged

if not strict skip this

4. exits with

  • conversion success = true
  • changed model


  1. This is fine for conversion of L1, L2 and L3 core
  2. Lucian would like it changed so rather than report just success or failure it could report things like
    1. 'success-model is still mathematically the same'
    2. 'success--model is complete but mathematically different'
    3. 'success--model is not complete'
    4. 'failure'
  3. If we leave this as is and introduce other functions for things you would do with packages the only package this function needs to deal with is layout.

Suggested API


My thoughts are that this will initially be the most requested function. Software will want to get rid of the parts of a model it does not wish to deal with. Whether the model is then mathematically meaningful is up to the tool to decide.

This would basically remove the package from the model. It would pass control to the package code to see if this involves more that just deletion. At this point comp would say 'you need to flatten the model to get rid of me' and Lucians flattening code would be called.

Note that a conversion to L2 would just call stripPackage successively for all packages present.

I think Lucians idea of return codes for these functions is a good one and will be necessary rather than a black and white result.


As packages develop we will need to change between versions of packages.


The big one; when we have L3V2 a conversion of the core version will involve converting the version of all packages. we will need to track which version each package was at when the new core version was introduced.

So we need functions in the package code that says I'm a valid version for this core version.


  1. All these functions will require the package code to do something - even if it is merely to communicate that the package can be stripped without consequence to the mathematics.

Retrieved from ""

This page was last modified 13:43, 15 July 2011.

Please use our issue tracking system for any questions or suggestions about this website. This page was last modified 13:43, 15 July 2011.