Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#259 FunctionDefinition restriction on 'delay' needs validation rule.

closed
nobody
5
2014-07-07
2014-04-21
Lucian Smith
No

When issue 163 (https://sourceforge.net/p/sbml/sbml-specifications/163/) was addressed in the L3v1 spec, no corresponding validation rule was added to ensure that 'delay' was not used in FunctionDefinitions. We will need to add this new validation rule to both L2v5 and L3v2.

Discussion

  • Lucian Smith
    Lucian Smith
    2014-04-21

    Just as a note: we should almost certainly not simply change validation rule 20304 to include 'delay' on its list of 'time' and 'avogadro'.

     
    • Lucian Smith
      Lucian Smith
      2014-06-26

      This turns out to be incorrect: we have done similar changes in the past, and libsbml reports the validation rule depending on the level and version being validated. So, going ahead and doing it this way!

      We technically don't have enough votes yet, but this is a pretty obvious discrepancy that could almost be classified as a typo, so while we do still need people to officially vote, I'm going ahead and incorporating this into SVN for both L2v5 and L3v2. If/when enough editors vote on it, I'll put it in the errata for both specs.

       
      Last edit: Lucian Smith 2014-06-26
  • Michael Hucka
    Michael Hucka
    2014-06-04

    I agree this is an issue and that a validation rule needs to be added.

     
  • Brett Olivier
    Brett Olivier
    2014-06-10

    I agree this is an issue and that a validation rule needs to be added.

     
  • Frank Bergmann
    Frank Bergmann
    2014-06-28

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

     
  • I agree this is an issue and that a validation rule needs to be added.

     
  • Lucian Smith
    Lucian Smith
    2014-07-07

    With enough editors voting, this issue has now been accepted, with conformance implications (since a validation rule has been changed). It is now listed in the errata for both specifications, and a fix has been incorporated into the SVN already, so it is now closed.

     
  • Lucian Smith
    Lucian Smith
    2014-07-07

    • status: open --> closed
    • Group: Reported-Proposed --> Accept-conformance-implications