#229 Proposal: add new functions to allowable MathML

[Lucian Smith]

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.

[Lucian Smith]

I agree with the proposed change and that it should be done.

[Chris Myers]

I am accepting this issue as valid.

[Lucian Smith]

I agree with the proposed change and that it should be done.

[Lucian Smith]

Bruce clarifies that it's 'rem' that is modulus, and that 'quotient' is integer division (which is a different thing entirely, and may not be desirable in SBML).

[Nicolas Le Novère]

I agree with the proposed change and that it should be done.

[Nicolas Le Novère]

Be careful, mod is both a function and an operator. Here we are talking about the function. This must be super-clear in the spec. But otherwise, yes. (it is part of mathml, it should be included ... Can-I have a implicit yest vote for any suggestion involving the extension of what we call the MathML subset?)

[Lucian Smith]

I'm setting this back to 'open' and making this the more general 'what should we add to MathML?' question.

So far, people agree on <rem> and <quotient>, and that if we're ever going to add something, we should add it now.

A much much longer discussion on the issue on sbml-discuss is at http://sbml.org/Forums/index.php?t=msg&th=2154&rid=0#msg_7991

[Frank Bergmann]

I agree with the proposed change (of including all non-array/set/vector functions) and that it should be done.

[Brett Olivier]

I agree with the proposed change (as summarized by Frank) and that it should be done.

[Nicolas Le Novère]

I agree with the proposed change and that it should be done.

[Michael Hucka]

I think we are trending towards the introduction of MathML extension packages, correct?

So what remains for us here is to decide whether any extensions to MathML in Core will be made. The ones that seem least likely to be controversial are the basic arithmetic operators:
- quotient
- rem
- max and min

[Chris Myers]

Please add implies to that list as it is simple, and should have gone in with all the other Boolean operators.

A => B is simply !A + B

but it is very useful to have it explicitly. We use it all the time.

Chris

[Michael Hucka]

It's fine by me to add it. It looked like such a fringe thing that I thought no one would care to have it, but hey.

[Lucian Smith]

OK, this has gone back and forth a few times with different ideas, and I believe there are three basic options we could go with. Editors, please vote on which one you believe we should do:

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.

The basic arguments for each, as I understand them:

1: this is the simplest to understand, and the most difficult to implement (but not horrible to implement).

2: This adds simple new capacities to core that will not put undue burden on developers, and still provides a way to provide other capabilities to tools that need them, through the packages.

3: This comes with zero cost to developers of core-only, provides a way to provide other capabilities to tools that need them, and even allows L3v1 models to use quotient, rem, max, min, and implies.

Personally, I would vote for 2. I think most people won't add support for random MathML packages unless we add them to core, and people have wanted several of those particular functions for years. I don't think the benefit of letting them exist in L3v1 is all that extensive, and if it was really important to someone, we could add a new L3v1 package with those five functions in it, anyway.

[Chris Myers]

While I don't have a vote anymore, I would agree that Option 2 is the best compromise.

Chris

[Brett Olivier]

My vote is for option 2.

[Michael Hucka]

It is worth pointing out that Sarah pointed out a benefit of option 3: the new math packages would be usable in L3v1 too.

[Chris Myers]

Lucian did point this out, but he also pointed out that if needed, could create a small L3V1 package for these functions and still make them part of core for L3V2.

Chris

[Sarah Keating]

Please do not add MathML things to L3V2 core AND have them as a L3V1 package - this presents a horrible situation when it comes to having the correct SBML namespaces present for a construct to be valid.

[Chris Myers]

In that case, I will would advocate option 2, since those who want these can without too much trouble move to L3V2.

Chris