#300 Be explicit in how packages can 'change mathematics'

[Lucian Smith]

In Andreas's comments on the L3v2 draft spec, there were several places where he felt we needed to say that (for example) the flux of a reaction could be defined by a package like FBC.

I don't think we need this everywhere, but do agree we should be more explicit in saying exactly how packages can override core math. Here's some draft text I currently placed at the end of section 4.1.3 ('package declarations') in the section on the 'required' flag:

---

Some ways in which packages which are marked required = “true” may actually change (instead of merely augment) the time-course dynamics of a package include:
• An element with mathematical meaning may have a value defined by a package which was left undefined in core.
• An element with mathematical meaning may have a value defined by a package that overrides the value it had in core.
• The definition of how an element changes in time may be added, changed, or augmented by a package.
• An element may be defined within a package to have mathematical meaning, and its ID may be used to determine one or more mathematical functions in core.

Anything I'm missing? Any suggestions for a better way to word anything? Is this a good place for it to go?

[Brett Olivier]

Package related stuff should be in package specifications and I completely agree that it should be left out of the core specification. The new text looks fine.

[Lucian Smith]

Here's another question: is it allowed for a package to take an ID from an element without mathematical meaning, and give it a mathematical meaning? Could a package say "The mathematical meaning of a Trigger is the Boolean value of its child Math object"?

My inclination is to say 'no'; that any ID either has mathematical meaning or not, as determined by the specification that defines it. Now that package specifications can define their own symbols to be used in math, this doesn't actually hinder anyone: they could define a 'package:boolID' attribute for Trigger, should they so choose, for example.

Either way, this section would be a good place to explicitly state this.

[Michael Hucka]

My feeling here is that we should try to avoid letting packages become a free-for-all. I think letting them change things radically, like give new meaning to things that were assumed not to have meaning, would be going too far.

[Sarah Keating]

I think the wording is fine for the core specificatiopn and I think you've got all the cases.

I agree with Mike that letting a package change too much will not be a way towards interoperability and support for packages.

[Nicolas Le Novère]

I agree with the wording.

And let's be warry of Babylon towers.

[Lucian Smith]

With a majority of editors agreeing, this change has been incorporated into SVN and will be part of the forthcoming L3v2 specification, with the additional line:

"However, no package may ever give mathematical meaning to the ID of an element that was defined as not having mathematical meaning: those IDs must never appear in any mathematical context."

(If anyone has an issue with this, please comment.)

It has also been added to http://sbml.org/Documents/Specifications/SBML_Level_3/Version_1/Core/Design_changes_planned_for_the_Level_3_Version_2_Core_Specification

[Lucian Smith]

With the release of l3v2, this issue is now resolved.