— the global portal for all things SBML

2011-09-02 During COMBINE

SBML Editors' meeting minutes

Editors present:
Editors absent:
Visitors present: (No visitors)
Location: HITs, Heidelberg

What is the "job description" for the cognizant editor of a PWG?

Here are the kinds of activities we foresee for the cognizant editor:

  1. Cheerleading the effort for a particular package
  2. Keeping aware of the progress, and reporting to the rest of the SBML Editors
  3. "Technical support":
    • When someone has a question about how to do things, they explain the "SBML way" of doing things
    • Tell the author(s) of the specification how to compose and structure such documents
    • Assessing implementations of the package
    • Help create test cases (of some sort—not necessarily STS cases, but something)

Still to decide:

  1. Does the person have to be a current editor?
    • Decision: a current editor has to be on the PWG, but this does not mean that this is the author of the spec or leading PWG discussions, and nothing prevents an editor whose term ends from continuing to be involved.
  2. Who creates test cases (preferrably test suite, but if it doesn't fit with what STS tests, then at least test models)?
    • Also include expected output (which may be written descriptions, if it's not operationally testable)
    • May need statement of matching criteria (i.e., what does it mean to be correct?) May need sampling, ranges, statistical properties
    • Decision: the members of the PWG should write the test cases

Which editor oversees which PWG ?

Editors get assigned at least by the time of acceptance of the package, but may happen earlier.

Just because Frank is listed for several packages does not mean that whoever replaces him as editor must also be assigned to those things.

Name Label PWG list Editor
Layout layout sbml-layout Frank
Flux Balance Constraints fbc sbml-flux Frank
Rendering render sbml-render Frank
Hierarchical Model Composition comp sbml-comp Lucian
Qualitative Models qual sbml-qual Sarah
Annotations annot sbml-annot Lucian
Spatial Processes spatial sbml-spatial Jim
Groups groups sbml-groups Mike
Required Elements req sbml-required Lucian
Multistate multicomponent species multi sbml-multi Sarah
Distribution & ranges distrib sbml-distrib Mike
Arrays & sets arrays sbml-arrays Chris
Dynamic structures dyn sbml-dynamic Chris

Is the (new) L3 development procedure settled?


We modified the part about "many users find useful".

We are not certain about this part of "validity after reduction":

A package cannot redefine or modify semantics of existing SBML Level 3 Core elements and attributes. For example, a 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.)

The problem is that this involves semantics, not just syntactic validity.

How do we best get feedback on our new scheme for package acceptance?

We should have a session here at COMBINE to talk about it, but also need to solicit feedback from the mailing list, and then get package champions to tell us if they think what they have written so far is sufficient. (-LS)

What should be required when stripping packages?

Only require Core validity if all packages are stripped. If have a model that uses 2 packages, A and B, and you only strip B, then there is no assumption of validity (because there may be dependencies between the packages that the software cannot understand)

The required flag works independently, and means, if it's true for a given package, if it's stripped then the remaining math has changed. (Implication: if all packages stripped from a model all had required=false, then the math is not expected to have changed, and the result is expected to be syntactically valid SBML L3 Core. In all cases, when stripping the packages, the result should be syntactically valid L3 Core.)

Should packages declare what other packages they depend upon?

We discussed a possible attribute that packages could declare, somewhat like the current required attribute, but listing the namespaces of packages that a given package depends upon. We decided not to do it for now, until we have an actual case where it's needed.

Are we ready to issue the call for votes for 'multi' and others?

What's required for a package specification in terms of format and content

Retrieved from ""

This page was last modified 16:51, 21 September 2012.

Please use our issue tracking system for any questions or suggestions about this website. This page was last modified 16:51, 21 September 2012.