[cellml-discussion] Include_in_CellML_1.2 requested: [Tracker Item 153] Allow multiple connections between the same pair of components
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] CellML Tracker Change Password Request
You have (or someone impersonating you has) requested to change your CellML Tracker password. To complete the change, visit the following link: http://bowmore.elyt.com/bugzilla/token.cgi?t=CJnHxg1unEa=cfmpw If you are not the person who made this request, or you wish to cancel this request, visit the following link: http://bowmore.elyt.com/bugzilla/token.cgi?t=CJnHxg1unEa=cxlpw If you do nothing, the request will lapse after 3 days (at precisely 11:24 on the 1st of September, 2007) or when you log in successfully. ___ 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
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
Re: [cellml-discussion] Include_in_CellML_1.2 requested: [Tracker Item153] Allow multiple connections between the same pair of components
Dear Andre, I appreciate that a change such as this would not be useful for you in terms of the way you set up your models. But I believe you have to consider the fact that every person who creates models has their own way of debugging or checking for errors. As such, this could (and would) be a useful change for those (such as myself) who like to list all the in connections to a component directly next to that component to be able to quickly see that they have made all the appropriate connections. I personally find this is a lot easier for debugging than having a big clump of connections at the end of a model. I appreciate that this may not conform to current best practice, but it works for me. But I'm not writing to debate the pros and cons of coding styles. It seems to me that this change would be useful to some users (namely myself and some others here at the Bioengineering Institute) and as it doesn't (in my mind at least) change the meaning of the CellML, I can't see why it should be an issue. Regards Jonna David Nickerson wrote: --- 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. 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. * 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. * 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. 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 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
Re: [cellml-discussion] Include_in_CellML_1.2 requested: [TrackerItem153] Allow multiple connections between the same pair of components
Hi Jonna, Jonna Terkildsen wrote: Dear Andre, I appreciate that a change such as this would not be useful for you in terms of the way you set up your models. But I believe you have to consider the fact that every person who creates models has their own way of debugging or checking for errors. As such, this could (and would) be a useful change for those (such as myself) who like to list all the in connections to a component directly next to that component to be able to quickly see that they have made all the appropriate connections. I personally find this is a lot easier for debugging than having a big clump of connections at the end of a model. I appreciate that this may not conform to current best practice, but it works for me. But I'm not writing to debate the pros and cons of coding styles. It seems to me that this change would be useful to some users (namely myself and some others here at the Bioengineering Institute) and as it doesn't (in my mind at least) change the meaning of the CellML, I can't see why it should be an issue. while I think I point out some issues in my previous emails, I'm certainly not trying to say that my way is the best, merely pointing out that there are CellML users happy with the current standard. I think you'll also find that using CellML 1.1 a lot of these problems go away as you only ever have one, or at most a few, components per model so you can easily achieve a coding style like your current one without needing to change the specification. I'm similarly not really interested in a debate on best practices for coding CellML XML by hand, just putting forward my objection to making such a change to the specification. Andre. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
