* Roland Keller <firstname.lastname@example.org> [2011-03-23 16:52] writes:
> Dear all,
> The SBML specification for Level 3 Version 1 states that the Trigger element in Events contains the non-optional attributes "persistent" and "initialValue".
> I just had a look into the SBML test suite and noticed that some models in Level 3 Version 1 lack the persistent attribute. See, for instance, model 406.
> To evaluate the Trigger element, I am using JSBML. This library's getPersistent() method returns false if no persistent attribute has been specified in Level 3. But for previous SBML levels, this method returns true. For these earlier SBML levels, this makes sense, because the behavior of a Trigger was defined as if it had the property persistent=true.
> However, I think there are two problems at the moment.
> 1. The test models seem to be not correct because the persistent
> attribute is not optional and has to be present. It seems to be
> forgotten in these examples.
This is the core issue, of course, and thanks for finding it--the models
need to be fixed. I believe they were created before the L3v1 spec was
finalized, and 'persistent' is one of those last-minute additions to the
Event syntax, so they *used* to be valid...
> 2. If this element is forgotten, how should we deal with it? Does the
> returned value "false" really make sense? I noticed that the test models
> could be simulated with much better quality if I simply set persistent
> to true if it was forgotten.
> So far, I have never used libSBML, but it would be interesting what the
> getPersistent() method in libSBML does in contrast to JSBML.
> For myself, I'd like to know what I can assume when dealing with the
> missing persistent attribute in Trigger for SBML Level 3.
If libsbml didn't have to bind to various languages, it would throw an
error. But since a boolean element can't have three states (true, false,
and error), it must return either true of false. What should be done by
the calling code is to call 'isSetPersistent' first, and only if that
returns true, to call 'getPersistent'. Alternatively, you could validate
the model before calling any 'get' functions, which would effectively
accomplish the same thing.
I believe that since jsbml has restricted itself to the java sphere, it
has the freedom to throw an error when encountering situations like this
(getting the value of an unset boolean), and it should definitely do so.
To manage your sbml-discuss list subscription, visit
For a web interface to the sbml-discuss mailing list, visit
For questions or feedback about the sbml-discuss list,