2011-09-02 During COMBINE
|Visitors present:||(No visitors)|
What is the "job description" for the cognizant editor of a PWG?
Here are the kinds of activities we foresee for the cognizant editor:
- Cheerleading the effort for a particular package
- Keeping aware of the progress, and reporting to the rest of the SBML Editors
- "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:
- 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.
- 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.
|Flux Balance Constraints|| ||sbml-flux||Frank|
|Hierarchical Model Composition|| ||sbml-comp||Lucian|
|Qualitative Models|| ||sbml-qual||Sarah|
|Spatial Processes|| ||sbml-spatial||Jim|
|Required Elements|| ||sbml-required||Lucian|
|Multistate multicomponent species|| ||sbml-multi||Sarah|
|Distribution & ranges|| ||sbml-distrib||Mike|
|Arrays & sets|| ||sbml-arrays||Chris|
|Dynamic structures|| ||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)
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
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.