Chronological Thread 

< Chronological >      < Thread >

---

Andrew Miller wrote:
> David Nickerson wrote:
>>> ------- Additional Comments from Andrew Miller <ak.miller at
>>> auckland.ac.nz>
>>> Section 3.2.4 of CellML 1.1 states, in the second sentence of the second
>>> paragraph: "Only one connection may be created between any given pair of
>>> components in a model".
>>>
>>> This is a fairly pointless restriction from all fronts:
>>> * From a model authors perspective, it creates a burden on the author to
>>> consolidate all their connections which may have been created for
>>> different
>>> purposes, and current model authors claim that such consolidation is time
>>> consuming and error prone.
>>>
>> I'm not sure why this is the case. I much prefer to know that in any
>> given model there is only one connection between two particular
>> components and that is the *only* place I need to look to add, remove,
>> or correct variable connections. If you allow multiple connections
>> between the same components then it becomes much more difficult to
>> locate extraneous connections, or perhaps software would simply use the
>> first (or last) defined connection and leave an author bewildered when
>> there model edits have no effect due to a missed connection element
>> earlier.
>>
>> I'm really not sure who you mean by "current model authors"? But I
>> consider such consolidation to be much less time consuming when editing
>> complicated models and, as mentioned above, much less error prone.
>>
>
> Jonna, James, and Catherine all agreed on this, although as you have now
> revealed, this is obviously not a unanimous view amongst model authors.

perhaps a reason to consider CellML users outside of Auckland before
putting forward such broad, sweeping statements?

> With regards to the 'would simply use the first (or last) defined
> connection and leave an author bewildered when there model edits have
> no effect due to a missed connection element earlier' issue, I think we
> can add clarifying text to make it absolutely clear that the correct
> interpretation is to take the union of all the variable pairs being
> connected (we need to find a clearer wording for this, because this
> could be confusing in the case where component_1 and component_2 are
> reversed, in which case the corresponding variables should of course be
> reversed).

sure - but this would be one more thing that existing tools would need
to do in order to be CellML 1.2 compliant. Seems we want to keep this
list as small as possible in order to help the community adoption grow.
Especially for the case where a model is valid CellML 1.0 apart from the
multiple connections.

>>> * From a model readability perspective, it is also burdensome because
>>> connections between variables may not be in a logical order (this is less
>>> of an
>>> issue if tools are used, but the point still holds).
>>>
>> I'm not sure the specification should be designed to make the XML
>> serialization look pretty - which is what you are saying here, right? If
>> you want this to hold then you would need to add rules such that
>> software is not allowed to change the order of the XML elements in a
>> serialized document.
>>
>
> I think that allowing inputs to look pretty is different to forcing it
> to look pretty. I don't think we should force all output generated by
> tools to look pretty, but allowing authors who like to work from the XML
> to input their models in a readable way is still a valid goal.

sure, and while I consider my way to look "pretty" and be significantly
more manageable, I can understand that different people have different
views on this issue. Again, possibly suggesting community discussion
rather than a proposal to change a fundamental rule in the CellML
specification. I know there was much debate when connections were first
being defined and for whatever reason it was decided to not allow
multiple connections between components. To me it seems that mere
aesthetics of the XML serialization of a model is not a significant
enough reason to justify revisiting the original decision when the 1.0
specification was written.

>>> * Implementation experience suggests that it is no harder to allow
>>> multiple
>>> connections between the same pair of components when writing simulation
>>> software, but the extra constraint imposes more work on developers when
>>> writing
>>> tools which try to validate the model.
>>>
>> This seems to be a good reason to keep the rule as it is. Given there is
>> already a sever lack of CellML validation tools it seems a bad idea to
>> be making it more difficult for people to write such tools.
>>
> I don't follow. Removing the constraint should make life easier for
> validation tools - it is one less thing they have to check.

ok - guess I misinterpreted your comment. However, given the only tools
close to CellML validators currently available already implement this
check, it would appear that its not too much work to do so.

>> So, I guess what I'm saying is that I object to including this in CellML
>> 1.2 - at the very least more discussion is needed to convince me this
>> should be done at all. So far I'm seeing one strong reason not to change
>> and no reason supporting the change...


Andre.

---

• [cellml-discussion] Include_in_CellML_1.2 requested: [Tracker Item 153] Allow multiple connections between the same pair of components, cellml-tracker at cellml.org, 08/29/2007
  • [cellml-discussion] Include_in_CellML_1.2 requested: [Tracker Item 153] Allow multiple connections between the same pair of components, Andrew Miller, 08/29/2007
    • [cellml-discussion] Include_in_CellML_1.2 requested: [Tracker Item 153] Allow multiple connections between the same pair of components, Alan Garny, 08/29/2007
    • [cellml-discussion] Include_in_CellML_1.2 requested: [Tracker Item 153] Allow multiple connections between the same pair of components, Matt, 08/31/2007
  • [cellml-discussion] Include_in_CellML_1.2 requested: [Tracker Item153] Allow multiple connections between the same pair of components, David Nickerson, 08/29/2007
    • [cellml-discussion] Include_in_CellML_1.2 requested: [Tracker Item153] Allow multiple connections between the same pair of components, Andrew Miller, 08/29/2007
      • [cellml-discussion] Include_in_CellML_1.2 requested: [TrackerItem153] Allow multiple connections between the same pair of components, David Nickerson, 08/29/2007
        • [cellml-discussion] Include_in_CellML_1.2 requested: [TrackerItem153] Allow multiple connections between the same pair of components, Jonathan Cooper, 08/31/2007
    • [cellml-discussion] Include_in_CellML_1.2 requested: [Tracker Item153] Allow multiple connections between the same pair of components, Jonna Terkildsen, 08/29/2007
      • [cellml-discussion] Include_in_CellML_1.2 requested: [TrackerItem153] Allow multiple connections between the same pair of components, David Nickerson, 08/29/2007

---

Archive powered by MHonArc 2.6.18.