The good thing about the existing rules is that you can see from the variable interfaces for a given component what needs to be defined externally and what may be used externally. While I can see your point about the way mathematical expressions could end up modifying different variables depending on how the entire model is defined, I'm not sure that we want to start allowing variables with an interface off "in" to be modified in any way.
I guess I'd prefer a set of rules that somehow flag "in" variables as constant within that component. If execution of the math in a particular instantiation of the component would result in any such constants having their value changed then that should be treated as an error. Essentially what the current rules state, but perhaps not quite the way the rules are being enforced in the CCGS? If we were to remove such rules, is there any need for the public and private interfaces at all? Andre. Andrew Miller wrote: > Hi all, > > The current (CellML 1.1) specification has some wording like the following: > > ''The variable must also be declared in these components, which can then > use the value of the variable in their own equations but must not modify > it." (3.2.3) > > > " > 4.4.4 > > * A mathematical expression defined using MathML must only modify > the values of variables that belong to the current component. > [ Variables that belong to a component are those that are not > declared with a |public_interface| or |private_interface| > attribute value of |"||in||"|. ] > > " > > It doesn't really make a lot of sense to talk about a mathematical > expression modifying a variable, because an equation really only > describes the relationships between variables, and doesn't specify which > variable is to be modified. At least in the current CCGS implementation, > exactly how an equation is used will vary depending on what other > components are connected to a given component, and so it is possible > that the rules would sometimes be met depending on what is connected to > a particular component, which is obviously not a robust way to develop a > model. > > I suggest that this requirement be dropped in the next version of CellML > (I am also making a list of other changes from 1.1 I am proposing, which > I will send to the mailing list when it is completed). > > Best regards, > Andrew > > _______________________________________________ > cellml-discussion mailing list > [email protected] > http://www.cellml.org/mailman/listinfo/cellml-discussion -- David Nickerson, PhD Research Fellow Division of Bioengineering Faculty of Engineering National University of Singapore Email: [EMAIL PROTECTED] _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
