#163 FunctionDefinition should disallow the use of 'delay'

[Michael Hucka]

As reported by Stefan Hoops to the sbml editors' list:
---------------------------------------------------------------------------

Hello All,

I am not aware that the SBML specifications restrict the use of the
csymbol delay. Which means we are allowed to use it in a function
definition. This creates a huge problem since the first argument of the
delay symbol is not a numerical value as for all other functions. It
identifies an object. This object may be virtual as we allow an
arbitrary expression as the first argument. Nevertheless it is
important to note that in no case the first argument is a number.

If one uses the delay symbol within a function definition this
connection to the object is lost as the arguments provided are only
numerical values.

Let us look at a simple example:

f(X, Y, delta) = delay(X + Y, delta)

And 2 kinetic laws:
v1 = k*[A]*f([A], [B], 0.5).
v2 = k*[C]*f([C], [B], 1.0).

We have 2 options to resolve the issue:

1) Disallow the delay symbol in function definitions
2) Specify that we need to substitute the function definitions in v1
and v2 with the definition of the function and replace the variables
with the values/identifiers provided within the call to f.

I prefer 1) in the interest of simplicity :)
---------------------------------------------------------------------------

[Lucian Smith]

The only question on the list was whether macro expansion should be the *required* method of resolving function definitions, and I think the answer was 'no, it shouldn't'.

[Lucian Smith]

I agree that the change should not be taken.

[Lucian Smith]

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

[Lucian Smith]

(whoops, selected the wrong response)

[Michael Hucka]

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

[Michael Hucka]

The discussion for this issue mostly took place in relation to tracker item #2964794:
https://sourceforge.net/tracker/?func=detail&aid=2964794&group_id=71971&atid=894711

There we decided that whatever was done in the L3 case should be done also for the L2 case. That's reached the consensus stage, so I'm just following up now to change the status of this one (for L2) to be "Pending" as "changes with conformance implications".

I'm adding the item to the errata list for L2v4r1.

MH

[Lucian Smith]

Fixed in SVN for L2v5, and will be part of the forthcoming release of that specification.