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: ak.miller at auckland.ac.nz (Andrew Miller)
  • Subject: [cellml-discussion] A list of proposed changes to semantics to makein CellML 1.2
  • Date: Sun, 23 Dec 2007 22:47:31 +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".

I think we also need "both" for the forwarding case if we were going to
take this approach.

This is a pretty fundamental change
> to the specification but I think that it better reflects the
> declarative intent of CellML model descriptions.

I think that if we want the bulk of valid CellML 1.1 models to be valid
CellML 1.2 models, we would need to at least keep the directionality as
an option, even if it carries information which is not meaningful in
CellML 1.2. This would mean 1.2 software could process most 1.1 models
without having to implement the two specifications separately, which is
probably a good goal to have.

I think that it all depends on how much we are prepared to change the
specification for CellML 1.2 - I have so far been aiming to get forwards
and backwards compatibility unless the model actually uses some feature
available in one version that isn't in another.

Best regards,
Andrew

>
> 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: 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



Archive powered by MHonArc 2.6.18.

Top of page