[cellml-discussion] A list of proposed changes to semantics to makein CellML 1.2

[Poul Nielsen]

Yes, the scheme that I proposed would not allow variables to 'pass  
through' the public_interface and private_interface of a component. I  
imagine that this could be inconvenient in some situations. We could  
enable this by adding a fourth value, 'public_private', to the  
attribute list.

Best wishes
Poul

On 2007 Dec 22, at 20:21, Jonathan Cooper wrote:

> 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: msn at jonc.me.uk      www: jonc.me.uk/
>>>
>>> We are tribbles of Borg. Prepare to be replicated.
>>> _______________________________________________
>>> cellml-discussion mailing list
>>> cellml-discussion at cellml.org
>>> http://www.cellml.org/mailman/listinfo/cellml-discussion
>>
>> _______________________________________________
>> cellml-discussion mailing list
>> cellml-discussion at cellml.org
>> http://www.cellml.org/mailman/listinfo/cellml-discussion
>
> -- 
> Jonathan Cooper      MSN: msn at jonc.me.uk      www: jonc.me.uk/
>
> I haven't lost my mind... It's backed up on tape somewhere.
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.cellml.org/pipermail/cellml-discussion/attachments/20071223/b9c37b07/attachment-0001.htm