On Sat, Dec 22, 2007 at 11:19:52AM +1300, Poul Nielsen wrote: > 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.
How would that work for a component like B below, which has both a public and private interface for the same variable? Jonathan. > 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 -- Jonathan Cooper MSN: [EMAIL PROTECTED] www: jonc.me.uk/ I haven't lost my mind... It's backed up on tape somewhere. _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
