— the global portal for all things SBML

2010-06-22 followup

SBML Editors' meeting minutes

Editors present: TBD
Editors absent: TBD
Visitors present: TBD
Location: videoconference using EVO
Scribe: Mike Hucka


Events: where do things stand?

There was a recent vote on 3 issues.

There is also the tracker item 2948747 about Events, and past email from Lucian:

From: Lucian Smith <> 
Subject: Re: [sbml-editors] Simultaneously-fired events 
Date: Sat, 6 Mar 2010 22:58:21 +0000 

Right--I think that if we clarify the base spec to indicate that only the  
first two cases are valid, then when we come up with an 'extended events'  
extension that allows people to declare the order of simultaneously-firing  
events, all our bases will be covered.  If Frank's interpretations are  
valid, defining the order won't help, so I want to make sure that *if* the  
order is known, only one thing can happen.

This follows up from earlier discussion on sbml-discuss and later at the hackathon ( and Chris's three proposals are:

  • Put a flag on the Event (or on the Trigger) that is mostly for delayed events (but also potentially for simultaneously-fired events) that says "this trigger must be true continually until fired, or else it should not fire at all"
    • What do we call it? Does it belong on the Trigger or the Event?
  • Add an optional 'priority' flag for simultaneous events. Ideally, you could assign values to these stochastically, but a simple value might do for now.
    • Events in the queue who are about to fire at the same time currently execute in an unspecified order. If no 'priority' was defined, this would still be true (unless we made 'priority' required).
    • Two simultaneously-fired events with different 'priority' values would execute in a determined order, highest priority first.
    • Two simultaneously-fired events with the same 'priority' value would execute in a randomly-determined order.
    • (re: Lucian's quoted email above) Regardless of firing order, the spec should say explicitly that each event's eventassignments can, in turn, add a new event to the queue, even if a subsequent simultaneous event overrides that event's trigger.
      • (Note: we should say explicitly that all EventAssignments happen 'as a block', and that it is incorrect to check if other events' triggers have been flipped after applying only a single EventAssignment in a list of EventAssignments.)
    • Probably belongs on the 'Event' element.
    • Applies to firing time, not triggering time (only different for delayed events, but worth specifying).
  • Add 'InitialValue' to triggers so we can say that the trigger is true or false before t=0 (the current setup effectively sets this to 'true'.) This will allow events to fire at t=0.
  • This should be written up and discussed on sbml-discuss.

Resolving current non-trivial, non-editorial issues in the tracker

There are a few issues in the tracker that are not typographical or trivial issues, and can stand some discussion. They are listed under separate headings below.

2964793 "SpeciesReference's constant should be conditionally optional"

  • Sarah's suggestion: make 'constant' optional if the SpeciesReference has no 'id'.
  • Frank's suggestion: make 'constant' optional for Species *and* SpeciesReferences unless that id appears within an Algebraic Rule. (It can be determined from context in all other cases, and serves only as an annotation and an error checking mechanism.)

2017553 "Can csymbol delay reference another delay?"

This issue was not brought up in the context of Level 3, but it was never resolved, and still applies to Level 3.

2948744 "Empty lists"

  • People want to annotate their empty lists, and if they can't exist, they can't annotate them. If we let them exist, they do not change any semantics, and can be annotated.

Can we add optional SIDs to the few remaining 1st-level elements that don't yet have them?


  • this would make the 'comp' package less reliant on xpath.
  • Allow cleaner UIs for manipulating these elements.


  • Pollutes SID namespace.
  • Introduces more SIDs that cannot be used in 'math' elements.

Brief thoughts from the 6/22 meeting: people are generally in favor of this, but it can't reasonably go into L3v1 since it's not an error, so it should go on the list for L3v2. Lucian then asked if it could go into the 'comp' package for now, until L3v2 came out, and people were of mixed opinions about that.

What procedure should be followed for finalizing/accepting L3 package proposals?

Current options:

  • Voting by the community
    • Original idea: vote between proposals
    • Vote between existing proposals and 'needs work' and 'this package should not be accepted at all'.
  • Review process?
    • Could be included with voting (either before or after)
  • Need to decide which option to pursue at which point in the process, and how we editors should be involved.

(Update: In May, Lucian mailed a suggestion to sbml-editors for a process akin to journal article review.)

Can we change 'rule' so that AssignmentRules and InitialAssignments are the same super-class? (from Nicolas)

Is a unit for 'occurrence' needed?

  • man what

Do units make sense as they are defined in L3v1?

Small tracker issues that need more votes in order to be moved forward

Retrieved from ""

This page was last modified 19:58, 21 September 2012.

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