|Editors present:||Mike Hucka, Frank Bergmann, Sven Sahle, Jim Schaff, Lucian Smith|
|Editors absent:||Darren Wilkinson|
|Visitors present:||(No visitors)|
|Location:||videoconference using EVO|
|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):
- Do not redefine the semantics of elements such that the specification of the core is invalid.
- 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.)
- 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.
- 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:
<listOfFunctionDefinitions> <functionDefinition id="foo"> <math xmlns="http://www.w3.org/1998/Math/MathML" xmlns:sbml="http://www.sbml.org/sbml/level3/version1/core"> <cn> 0.5 </cn> </math> <distrib:call xmlns:distrib="http://www.sbml.org/sbml/level3/version1/distrib/version1" function="gaussian" mean="2" variance="1.5" </distrib:call> </functionDefinition> </listOfFunctionDefinitions>
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 (
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? http://sbml.org/Community/Wiki/SBML_Level_3_Proposals/Required_Elements