#229 Proposal: add new functions to allowable MathML


People seem to be using the modulus function a fair amount (it's been in Copasi for ages, translated to ugly-looking mathML), so it would be good to add those two functions to the list of allowable MathML in L3v2 core.

EDIT: Updated to make this the general tracking item for 'what MathML elements should we add to the allowable subset of MathML'

EDIT #2: After some discussion, we now have three options:

1) Add all the MathML we discussed at HARMONY to L3v2 core (basically, all the functions that are either useful or easy to implement), and put other sets into MathML-only packages.

2) Add only quotient, rem, max, min, and implies to L3v2 core (basically, all the functions that are both useful and easy to implement); put other sets into MathML-only packages.

3) Add no new MathML to core; instead, add all the MathML we discussed at HARMONY including quotient, rem, etc. into domain-specific MatHML-only packages.


<< < 1 2 (Page 2 of 2)
  • Michael Hucka

    Michael Hucka - 2014-06-27

    I am not too sure about the "without too much trouble move to L3v2". Right now, with the other changes accepted for L3v2, I think it's looking not that easy.

  • Lucian Smith

    Lucian Smith - 2014-06-26

    Thus far, we have had a single editorial vote for option 2 ('add quotient, rem, max, min, and implies to L3v2 core'). Remaining editors, please vote; in the meantime, I am going to assume that Brett's vote (and other non-editor votes) is indicative of the future trend, and go ahead and incorporate that option into SVN for now. If people change their minds, we can revert the change.

    Assuming no other contrary discussion/votes, this change will be incorporated into the upcoming draft specification for L3v2.

  • Michael Hucka

    Michael Hucka - 2014-06-27

    On balance, I agree with option 2 as well. While I think it would be better to introduce it as a package, so that it could potentially be used in L3v1, it would require writing up a package specification, going through the package ratification process, etc. By the time all that's done, people will probably have implemented L3v2 support!

    So, another vote for option 2.

  • Frank Bergmann

    Frank Bergmann - 2014-06-28

    My vote is for option 2 as well.

  • Nicolas Le Novère

    I voted, I vote, I will vote for 1. My second choice is 2.

  • Andy Somogyi

    Andy Somogyi - 2014-07-05

    Not sure if it has been discussed, but it would be very useful if the spec had built in sgn and Heaviside theta functions.

    • Lucian Smith

      Lucian Smith - 2014-07-08

      Neither 'sgn' nor Heaviside theta are MathML functions--the full list can be found at http://www.w3.org/TR/MathML2/appendixc.html . If it was desired to add those to SBML directly (and not indirectly through a function definition), one would need to design and promote a package that had them in it, perhaps one like the 'distributions' package.

      Last edit: Lucian Smith 2014-07-08
  • Lucian Smith

    Lucian Smith - 2014-07-08

    Thus far, we have two votes for option 2 (Brett and Frank), and one vote for option 1 with a backup vote for option 2 (Nicolas). This means we still need Sven and/or Dagmar to vote or to explicitly abstain, to decide between options 1 and 2 (option 3 is no longer in the running).

  • Dagmar Waltemath

    I am accepting this issue as valid.

    I prefer option (1) because I actually would like to support all Math and let people decide what to use in their model encodings (believing that things will regulate themselves).

    However, otpion (2) is also fine with me, as it only delays the realisation of option (1) until we extend the supported Math next time ;)

  • Lucian Smith

    Lucian Smith - 2014-07-09

    Thanks! That makes it two votes that prefer option 1, and two votes that prefer option 2, meaning that Sven has the deciding vote, though if he decides to abstain, Mike's vote would push things to option 2.

    Though I don't have a vote, here's my own thinking at this point: while I do think that some MathML constructs belong in themed packages (like arrays or differentials), the fact that there's no theme for the package proposed in option 2 other than "Here are a bunch of functions that shouldn't be too hard to implement," doesn't make a very compelling use-case (and if you did break everything down into themed groups, that'd be too many packages!) If a simulator doesn't support a particular math construct, it seems like it's simplest just to look for that construct in particular, rather than looking for a mish-mash package that happens to also include that construct, but which might also include constructs that it does support.

    (The same argument wouldn't apply to packages like arrays, where all the new constructs are thematically linked, and if you support one, you should support them all, and if you don't support one, you probably don't support any.)

    So I think I would add my voice (if not my vote) in support of option 1.

    • Chris Myers

      Chris Myers - 2014-07-10

      Hmm, I thought your argument was heading to option 2. The items in option 1 but not option 2, I think group well such as "statistics" (mean, variance, etc.) and "sequences" (sum, prod).

      As for people voting for option 1 because they want all mathML, option 2 actually still allows all of mathML. The only difference is that if you want a part of mathML above the recognized subset, you must add a namespace to your document indicting that your model requires additional constructs. From a tool developers standpoint, this greatly simplifies support. One does not need to search the file to see if there is mathML that the tool does not recognize, they only need to look at the namespaces. The tool can then report to the user when they encounter a file that includes mathML constructs they cannot support. A new namespace can be added for any additional mathML constructs folks actually want.



      Last edit: Lucian Smith 2014-07-10
  • Michael Hucka

    Michael Hucka - 2014-07-11

    I reverse my position. I feel Lucian's and Nicolas' arguments are more convincing, when taken in the context of modelers and the long-term survival of L3v2. So, option #1.

  • Michael Hucka

    Michael Hucka - 2014-07-25

    Thanks! That makes it two votes that prefer option 1, and two votes that prefer option 2, meaning that Sven has the deciding vote, though if he decides to abstain, Mike's vote would push things to option 2.

    It appears we only need Sven's opinion on this, and we would be able to close the issue.

    Sven, I don't mean to nag, but ...?

  • Brett Olivier

    Brett Olivier - 2014-08-04

    I've been considering Lucian's argument above and it is making more sense. However, I do think developers should then be assisted in discovering which math functions are used in the model.

    Could libSBML return a list of mathML functions (and containing element?) used in the model? If something like this was possible I'd also consider supporting option 1.

    • Frank Bergmann

      Frank Bergmann - 2014-08-04

      Everything is implementable in libSBML, however decisions for the core should be made without libSBML in mind.

      Many of the function definitions we included at HARMONY, will be crippled if introduced via option #1. (For example, having to write all elements to be summed over into the expression is not any more helpful than using the n-ary plus that is already in core). So that will not help, a dedicated math package might help if it sorts out these things. Thus I remain for #2. That will solve immediate needs in the community, and leaves the door open to develop the math packages for the remaining operations in a meaningful way.

  • Brett Olivier

    Brett Olivier - 2014-08-04

    True, thanks for reminding me of those HARMONY points again (and libSBML) I'll stick with 2.

    Last edit: Brett Olivier 2014-08-04
  • Sven Sahle

    Sven Sahle - 2014-08-06

    Sorry for being very late here.

    I prefer option 2.

  • Lucian Smith

    Lucian Smith - 2014-08-06
    • status: open --> closed
    • Group: Reported-Proposed --> Accept-conformance-implications
  • Lucian Smith

    Lucian Smith - 2014-08-06

    OK, Option #2 wins! Conveniently, that was the version currently in SVN, so this issue is now closed and accepted/conformance implications. The change will be part of the forthcoming L3v2 specification.

  • Lucian Smith

    Lucian Smith - 2015-10-28

    Nico noticed that this change was not listed on the 'list of design changes for L3v2' page: it has now been added (http://sbml.org/Documents/Specifications/SBML_Level_3/Version_1/Core/Design_changes_planned_for_the_Level_3_Version_2_Core_Specification).

<< < 1 2 (Page 2 of 2)

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks