First login?
Lost password?
 
 
cellml-discussion AT lists.cellml.org 
CellML Discussion List

Text archives Help


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


Chronological Thread 
  • From: p.nielsen at auckland.ac.nz (Poul Nielsen)
  • Subject: [cellml-discussion] A list of proposed changes to semantics to makein CellML 1.2
  • Date: Sun, 23 Dec 2007 22:24:47 +1300
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



Archive powered by MHonArc 2.6.18.

Top of page