|Editors present:||Frank Bergmann, Mike Hucka, Sven Sahle, Lucian Smith|
|Editors absent:||Jim Schaff, Darren Wilkinson|
|Visitors present:||(No visitors)|
|Location:||videoconference using EVO|
|Recording(s):||EVO recording zip archive|
Does the package
required flag indicate "required for simulation", or "to fully understand"?
The meaning of the
required flag for an SBML Level 3 package is not fully clarified. If
required="true", does it mean that a software tool must understand the package in order to read the model, or in order to simulate/analyze the model numerically? Sven proposed the following over the sbml-editors mailing list on 30 April 2010:
[We] could just add "mathematics of the" [in the definition of the flag in the spec]: the “required” ﬂag indicates whether the mathematics of the model can be fully understood without understanding the package". To be more exact in future releases we could say: "Required =false" means that it gives correct results to interpret the maths of the model according the the core specs only. (Allowing the case where a package adds mathematical meaning, which is not required). Now that I think of it, may be we should actually change this in the spec now.
In discussions between Frank, Sven and Mike on 2010-05-13, we concluded the following. First, this issue is bound up with the issue of defining guidelines for L3 package definitions. Second, the above appears to be a good solution. If we follow through on the goal of defining packages in a way that tools can "fail gracefully" if they do not understand a given L3 package, then the consequence for that tool will be that reading only a model's core constructs will produce some behavior, but not the complete mathematical behavior of the intended model.
The policy for L3 Core is "no defaults", but is that policy forced on packages too?
Ralph Gauges asked during the hackathon whether packages can define some attributes to be optional with default values. Subsequent over an email discussion with Mike, he provided 2 examples motivating the question, both of them involving the layout & rendering packages:
- The layout package has a coordinate attribute for the z coordinate. Since most diagrams are 2-dimensional, z = 0 for the vast majority of models. In other (non-SBML) contexts, it is often conventionally assumed that if a z coordinate value is not given, the value can be assumed to be 0.
- The render package uses a kind of inheritance. For example, if a group of objects sets a certain fill color, this fill color is inherited by all members of the group that don't override the value explicitly. So now the question, is what value should the attributes be given if they cannot be optional with a default value? Writing
foo="inherited"for an attribute
foowould be one solution, but an awkward one. OTOH, it is probably infeasible to say that the attributes on the subobjects should take on the explicit color value (e.g.,
foo="green"), because this has subtly different semantics: inheritance of attribute value means "take the value from the parent", not "the value is green".
We need to decide how to handle these cases.
From Lucian: This strikes me as being very similar to how core treats units. If the model defines units, subelements inherit those units unless they explicitly override them. This seems similar, with the caveat that it's slightly different since the top element is required to have a fill color (I assume) while the model is not required to have units.
That said, I can easily see this as a tool issue, and simply require it to write 'green' everywhere. Then again, it makes it slightly harder to change everything at once in a tool that imports it... I could probably go either way.
After further discussions, Sven, Frank, Lucian and Mike agree with Lucian's first point. We concluded that attributes may be left optional, but such attributes must either inherit a value from a higher level object, or else the package specification must give a meaning to the case when a value is not given at all. For example, in Ralph's first example (the z values), the definition of the package could stipulate that objects without a z value are to be interpreted as 2-dimensional objects, whereas objects with a z value are to be interpreted as 3-dimensional objects, all without requiring a default value for z.
The question came up of whether the no-defaults rule must be followed by packages, or only "should" be followed. We concluded that we can only say we "strongly recommend" the no-defaults rule be followed by packages, but we cannot require it because at this time, we do not know the space of all possible packages and their needs.