Re: [sbml-required] Updates

[Sarah K. <ske...@ca...>]

Firstly - yes this is a great way to go :-)

BUT

You can guess what I am going to say -

where is my listOfMathChanged element :-)

Up to this point SBML has very clearly always had a containing listOfXYZ 
element that acts as a parent to the children in the list. Here (and 
also in current groups discussion) we are starting to change this 
policy. Do we need to actually review that as an overall strategy ?

Programmatically it is extremely useful having a base ListOf class from 
which these listOf elements are derived. Obviously the class derived 
from a ListOf does not *have* to be called listOfXYZ.  However the 
situation here is going to be slightly more difficult - since there is 
actually no intervening container between the SBase object and the 
children (that might or might not be in a listOf).

Yes I know there can be a dummy parent object but users of SBML in OO 
situations (yes libSBML but also JSBML or any other implementation) are 
used to having a correspondence between classes in code and elements in 
SBML. I have to say I find the comp libsbml code a little confusing 
because it does introduce some classes that are not reflected in the spec !

Also it does not hurt (it just makes the xml bigger!) to have a 
listOfMathChanged and it clearly indicates to people that there can be 
more than one. We have no other situation in SBML when an element can 
contain more than one child of the same type; where there is not a 
parent listOfXYZ element that contains these.

Sarah

PS Yes I know "listOfMathChanged" does not quite work as a name :-)