— the global portal for all things SBML


SBML Editors' meeting minutes

Editors present: Mike Hucka, Frank Bergmann, Sven Sahle, Jim Schaff, Lucian Smith
Editors absent: Darren Wilkinson
Visitors present: (No visitors)
Location: videoconference using EVO
Scribe: Mike Hucka
Recording(s): EVO recording zip archive


What rules should be followed by a tool that doesn't understand a required package?

Nicolas Le Novère started a thread on sbml-discuss where he made several proposals that impact how packages are defined. We need to decide whether we agree with them, or which ones. To summarize (and give them numbers for reference below):

  1. Do not redefine the semantics of elements such that the specification of the core is invalid.
  2. Ignoring elements with the package namespace should result in syntactically correct models that you can 'do things with', even if the mathematics will be wrong (visualize, annotate, edit to add/remove elements, etc.)
  3. It would be nice to allow encoding of a non-package version of a core element for programs that do not read your package. A 'random' function might be written in such a way as to always return '0.5' if the software did not understand the 'distrib' package.
  4. What happens if several packages need to be used concurrently, and particular symbols defined in different packages are used in the same mathematical expression? (Can we think of an example?)

(2010-06-09 comment by Mike) The approach for FunctionDefinition that we discussed at the Hackathon in the context of the distrib package would seem to satisfied goals 1–3. The approach was to subclass FunctionDefinition to produce a new type of FunctionDefinition that add a separate math element in parallel, like this:

    <functionDefinition id="foo"> 
        <math xmlns="" 
             <cn> 0.5 </cn>
        <distrib:call xmlns:distrib=""    
             function="gaussian" mean="2" variance="1.5"

The user of the distribution package would have to know what it means to call the function named gaussian in the package, as well as the arguments that it takes (mean, variance, etc.). The semantics of calling the function would be that the distrib:call part should be used and the math ignored, by software that understand distrib. If a software system didn't understand it, it could still use the function definition, and would simply end up with 0.5 as the value as a fall-back provided by the creator of the model for just those situations.

Added 6/17: Lucian wrote up a quick description of a 'required elements' package. Thoughts?

Retrieved from ""

This page was last modified 15:42, 22 June 2010.

Please use our issue tracking system for any questions or suggestions about this website. This page was last modified 15:42, 22 June 2010.