Re: [cellml-discussion] Include_in_CellML_1.2 requested: [Tracker Item 153] Allow multiple connections between the same pair of components

2007-08-30 Thread Matt
Semantically I think this is fine and theoretically does not change
the meaning of connections.

It's important to highlight that software developers will need to:

1) relax the validation constraint for the existing rule (i.e. only
one connection between any two components)
2) understand that component_1 and component_2 of map_components can
change order over connection elements between the same components
(some software may have used the current notion of there being only
one connection and one order to component_1 and component_2 to
optimise in memory object references)

I think this could have some pronounced effects on some software.

I wouldn't mind reworking the connection syntax altogether ... but
that's another proposal.




On 8/29/07, Andrew Miller [EMAIL PROTECTED] wrote:
 Hi all,

 Are there any objections to marking this as something we should include
 in CellML 1.2?

 Best regards,
 Andrew

 [EMAIL PROTECTED] wrote:
  Andrew Miller [EMAIL PROTECTED] has asked  for Include_in_CellML_1.2:
  Tracker Item 153: Allow multiple connections between the same pair of
  components
  http://bowmore.elyt.com/bugzilla/show_bug.cgi?id=153
 
  --- Additional Comments from Andrew Miller [EMAIL PROTECTED]
  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.
* 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).
* 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.
 
  To fix this, we could simply drop the first two sentences of the second
  paragraph of Section 3.2.4, and perhaps replace them with a short 
  explanation.
  ___
  cellml-discussion mailing list
  cellml-discussion@cellml.org
  http://www.cellml.org/mailman/listinfo/cellml-discussion
 

 ___
 cellml-discussion mailing list
 cellml-discussion@cellml.org
 http://www.cellml.org/mailman/listinfo/cellml-discussion

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] Include_in_CellML_1.2 requested: [Tracker Item 153] Allow multiple connections between the same pair of components

2007-08-28 Thread cellml-tracker
Andrew Miller [EMAIL PROTECTED] has asked  for Include_in_CellML_1.2:
Tracker Item 153: Allow multiple connections between the same pair of
components
http://bowmore.elyt.com/bugzilla/show_bug.cgi?id=153

--- Additional Comments from Andrew Miller [EMAIL PROTECTED]
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.
  * 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).
  * 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.

To fix this, we could simply drop the first two sentences of the second
paragraph of Section 3.2.4, and perhaps replace them with a short explanation.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] Include_in_CellML_1.2 requested: [Tracker Item 153] Allow multiple connections between the same pair of components

2007-08-28 Thread Alan Garny
Agreed, but we should then also delete (?) the second point of rule 3.4.5.4
(Proper use of the component_1 and component_2 attributes for the
map_components element).

Alan.

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:cellml-discussion-
 [EMAIL PROTECTED] On Behalf Of Andrew Miller
 Sent: 29 August 2007 01:13
 To: CellML Discussion List
 Subject: Re: [cellml-discussion] Include_in_CellML_1.2 requested: [Tracker
 Item 153] Allow multiple connections between the same pair of components
 
 Hi all,
 
 Are there any objections to marking this as something we should include
 in CellML 1.2?
 
 Best regards,
 Andrew
 
 [EMAIL PROTECTED] wrote:
  Andrew Miller [EMAIL PROTECTED] has asked  for
 Include_in_CellML_1.2:
  Tracker Item 153: Allow multiple connections between the same pair of
  components
  http://bowmore.elyt.com/bugzilla/show_bug.cgi?id=153
 
  --- Additional Comments from Andrew Miller
[EMAIL PROTECTED]
  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.
* 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).
* 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.
 
  To fix this, we could simply drop the first two sentences of the second
  paragraph of Section 3.2.4, and perhaps replace them with a short
 explanation.
  ___
  cellml-discussion mailing list
  cellml-discussion@cellml.org
  http://www.cellml.org/mailman/listinfo/cellml-discussion
 
 
 ___
 cellml-discussion mailing list
 cellml-discussion@cellml.org
 http://www.cellml.org/mailman/listinfo/cellml-discussion

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion