I think that Jonathan is correct - the concept of 'in' and 'out' does not make sense in a declarative description. One way to remedy this would be to remove the 'public_interface' and 'private_interface' attributes from the <variable> element and replace them with an 'interface' attribute which could assume values "public", "private", or "none". This is a pretty fundamental change to the specification but I think that it better reflects the declarative intent of CellML model descriptions.
Best wishes Poul On 2007 Dec 22, at 03:20, Jonathan Cooper wrote: > On Thu, Dec 20, 2007 at 12:30:32AM +0800, David Nickerson wrote: >>> * The current specification says: >>> "A variable with either a private_interface or public_interface >>> attribute >>> value of "in" must be mapped to no more than one other >>> variable in the >>> model. [ Note that a similar restriction does not apply to >>> variables with >>> interface values of "out". An output variable can be mapped to >>> multiple >>> input variables in various components in the current model. ]" >>> >>> The problem with this is that it doesn't properly account for >>> mappings where a variable is forwarded into an encapsulated >>> block. As >>> an example, consider the following encapsulation hierarchy (higher >>> components encapsulate lower ones)... >>> >>> A >>> | >>> B >>> / \ >>> C D >>> >>> Suppose that component A has, for variable v, >>> public_interface="none", private_interface="out", and B has for >>> variable v, public_interface="in", private_interface="out" >>> (connected to A), and C and D have public_interface="in", >>> private_interface="none", both of which are connected to B. >>> >>> There is no reason why this should not be valid. However, the >>> specification contradicts itself on whether this is allowed. On >>> one >>> hand, because B has private_interface="out", it "can be mapped to >>> multiple input variables in various components in the current >>> model.", but because it has a public interface of in, it "must be >>> mapped to no more than one other variable in the model". >>> >>> This can be fixed by firstly defining the interpretation of >>> connections and interfaces, and then adding constraints based on >>> that which actually describe which connections are allowed to each >>> set of variables. >> >> will be interesting to see how such a definition ties in with the >> idea >> of input variables becoming output variables based on the way the >> components are hooked together :) > > Indeed. > > The use of "in" and "out" on interfaces very strongly implies that > connections have a directionality, and this is also reflected in the > quote from the specification above - it assumes that variables are > only > defined in one place, and hence it doesn't make sense to import a > variable (via an "in" interface) from multiple locations. It does > however make sense to export a variable to multiple locations, or > forward > an imported variable to multiple locations (the example Andrew gives). > > If we don't want connections to have directionality, then I think this > requires quite a major change in the specification, even if only to > avoid > user confusion. For example, I would want to deprecate the use of > "in" > and "out", and instead allow public_interface="yes" or > public_interface="no" (perhaps a synonym for "none") and similarly for > private interfaces. The terms used in the language then reflect the > nature of the interfaces - if connections are bidirectional, then it > doesn't make sense to talk of an "in" interface, since it may function > either as input or output depending on the other components in the > system. > > Jonathan. > > -- > Jonathan Cooper MSN: [EMAIL PROTECTED] www: jonc.me.uk/ > > We are tribbles of Borg. Prepare to be replicated. > _______________________________________________ > cellml-discussion mailing list > [email protected] > http://www.cellml.org/mailman/listinfo/cellml-discussion _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
