Re: [cellml-discussion] Survey on opinions for the backwardscompatibility levels for future CellML Specs
I agree with Poul, especially in regard to having API implementation and translation tools available at the time of transition. Also, where it is not feasible to automatically translate a model such that it is compatible with a new specification there must be well documented processes for model authors to follow in order to manually transition their models. Andre. Poul Nielsen wrote: > I think that the best policy is to evolve CellML toward a clean and > simple specification. I don't think that this means that we require a > complete break with previous specifications at each major iteration > if, for example, we use deprecated/obsolescent flags. I believe that > it is essential, however, that we provide a mechanism for adding and, > importantly, removing elements and attributes. > > We have discussed previously the option of retaining deprecated/ > obsolescent elements/attributes for one or several iterations with a > view to maintain compatibility, but signaling that more appropriate > constructs are available and that such features are marked for > deletion. Examples of what is at issue here are suggestions that (1) > the reaction element be removed and (2) the public_interface and > private_interface elements be removed or their attributes be > modified. Deprecation has the advantage of offering a more gentle > transition, allowing models expressed in older, but not every, > iteration specification to be interpreted. It has the disadvantage > that it may not provide a clean break, making it difficult to deal > with the addition of new features that may be incompatible with old > ones. In both scenarios it will be important to provide tools to > translate older models into newer versions that conform to later > specifications. > > Because I think that it is important to be able to remove elements/ > attributes, I am not in favour of option A. Like Mike, I have a > problem with the statement that "[future versions] may remove > functionality that does not have an established base of software > which correctly implements that functionality". If the addition or > removal of elements or attributes results in a better specification, > then I think that consideration should be made for such changes > irrespective of whether there is "an established base of software > which correctly implements that functionality". My preferred option > is C, with the proviso that translation tools and APIs, conforming to > the new specification, be made available at the time of transition. > > Best wishes > Poul > > On 2008 Jan 09, at 11:58, Andrew Miller wrote: > >> Hi all, >> >> There have recently been some discussions of changes which would >> drastically break forwards or backwards compatibility of CellML (for >> example, changing the way that connections work). >> >> I think that it is important that we come to some consensus on what >> the >> policy for inter-version compatibility in CellML should be quite soon, >> because this drastically affects decisions that need to be made in >> CellML specification development. >> >> It doesn't really make sense to be inconsistent with respect to >> version >> compatibility - it would be quite unfortunate if we worked hard to >> keep >> compatibility for one part of CellML, and then broke it in another >> major >> part such as by changing the way connections work, and so I think we >> need a policy on this. >> >> I have come up with a number of different potential policy >> statements on >> when backwards compatibility should be broken and when it should be >> kept. It might help us to reach consensus if members of the CellML >> community could rank the policies in order of preference (1 is the >> most >> preferable policy, 2 the next most, and so on), and suggest any good >> policies that may be missing. >> >> Option A) >> Future versions of CellML should aim to solely express the >> intention of >> previous versions better and more clearly. They should aim to keep >> full >> compatibility with an implementation of the specification according to >> the rules of the specification as they were interpreted by >> implementors. >> >> Option B) >> Future versions of CellML should try to be mostly compatible with >> existing implementations of previous versions of CellML. They may >> remove >> functionality that does not have an established base of software which >> correctly implements that functionality. They may also add in new >> functionality, if that new functionality significantly increases the >> expressiveness of the language. However, in normal circumstances, >> compatibility should be maintained, so that when a model not using new >> features is saved in the new version's most preferred format, it can >> still be correctly loaded into software only supporting the old >> version. >> Likewise, a model not using any removed features should be able to be >> loaded in software supporting on
Re: [cellml-discussion] Survey on opinions for the backwards compatibility levels for future CellML Specs
James Lawson wrote: > Andrew Miller wrote: >> Hi all, >> > Hi, thanks for providing a nice intro to this issue Andrew. >> There have recently been some discussions of changes which would >> drastically break forwards or backwards compatibility of CellML (for >> example, changing the way that connections work). >> >> I think that it is important that we come to some consensus on what >> the policy for inter-version compatibility in CellML should be quite >> soon, because this drastically affects decisions that need to be made >> in CellML specification development. >> >> It doesn't really make sense to be inconsistent with respect to >> version compatibility - it would be quite unfortunate if we worked >> hard to keep compatibility for one part of CellML, and then broke it >> in another major part such as by changing the way connections work, >> and so I think we need a policy on this. >> > I certainly agree with you that we need to keep policy consistent. > However the possibility that immediately came to mind is that we could > group versions of the specification with respect to interversion > compatibility. If we have major decisions to make regarding the > continuing integrity of the language that might break compatibility, I > think we must reserve the right to do this, giving careful > consideration of the impact to the community of course. For example, > if we were to break compatibility of 1.0 and 1.1 with 1.2, but have > 1.3 and 1.4 compatible with 1.2, this would reduce development > workload compared with a policy of not requiring version compatibility > between successive versions at all. Perhaps this is an approach we > might want to take between, say CellML 1.X and CellML 2.X - that is, > we reserve major changes that will break compatibility for major > versioning events. One thing which I didn't state as clearly as I probably should have is that I am proposing that we decide on a policy for how we deal with the next version of CellML. By policy, I mean a uniting concept which applies to all issues in the development of the next version of the specification, as opposed to something which would apply across specification versions. I am not suggesting that we need to set a policy in stone for all future versions - it is likely that decisions like this will be reviewed by the community when we are working on post-1.2 versions of CellML if there need to do so. Best regards, Andrew >> I have come up with a number of different potential policy statements >> on when backwards compatibility should be broken and when it should >> be kept. It might help us to reach consensus if members of the CellML >> community could rank the policies in order of preference (1 is the >> most preferable policy, 2 the next most, and so on), and suggest any >> good policies that may be missing. >> >> Option A) >> Future versions of CellML should aim to solely express the intention >> of previous versions better and more clearly. They should aim to keep >> full compatibility with an implementation of the specification >> according to the rules of the specification as they were interpreted >> by implementors. >> >> Option B) >> Future versions of CellML should try to be mostly compatible with >> existing implementations of previous versions of CellML. They may >> remove functionality that does not have an established base of >> software which correctly implements that functionality. They may also >> add in new functionality, if that new functionality significantly >> increases the expressiveness of the language. However, in normal >> circumstances, compatibility should be maintained, so that when a >> model not using new features is saved in the new version's most >> preferred format, it can still be correctly loaded into software only >> supporting the old version. Likewise, a model not using any removed >> features should be able to be loaded in software supporting only the >> new version of the specification. >> >> Option C) >> Future versions of CellML should make any changes which make it >> conceptually cleaner, even if there is a less clean compromise >> available that would have lesser compatibility implications. Software >> will need to explicitly support more than one version as a completely >> separate format. >> >> My preferred choice is Option B. Despite being apparently at opposite >> ends of the spectrum, Option A and Option C are, in my opinion, >> fairly similar, because if we adopted Option A, larger changes would >> appear in a new specification called something other than CellML. >> Although there could be advantages of coming up with a more >> meaningful name than CellML, I think that this would also set us back >> in terms of community awareness of the specification, and so I think >> that Option C is marginally better than Option A (i.e. my personal >> order of preference is currently B:1, C:2, A:3). >> > I would have to concur
Re: [cellml-discussion] Survey on opinions for the backwards compatibility levels for future CellML Specs
Andrew Miller wrote: Hi all, Hi, thanks for providing a nice intro to this issue Andrew. There have recently been some discussions of changes which would drastically break forwards or backwards compatibility of CellML (for example, changing the way that connections work). I think that it is important that we come to some consensus on what the policy for inter-version compatibility in CellML should be quite soon, because this drastically affects decisions that need to be made in CellML specification development. It doesn't really make sense to be inconsistent with respect to version compatibility - it would be quite unfortunate if we worked hard to keep compatibility for one part of CellML, and then broke it in another major part such as by changing the way connections work, and so I think we need a policy on this. I certainly agree with you that we need to keep policy consistent. However the possibility that immediately came to mind is that we could group versions of the specification with respect to interversion compatibility. If we have major decisions to make regarding the continuing integrity of the language that might break compatibility, I think we must reserve the right to do this, giving careful consideration of the impact to the community of course. For example, if we were to break compatibility of 1.0 and 1.1 with 1.2, but have 1.3 and 1.4 compatible with 1.2, this would reduce development workload compared with a policy of not requiring version compatibility between successive versions at all. Perhaps this is an approach we might want to take between, say CellML 1.X and CellML 2.X - that is, we reserve major changes that will break compatibility for major versioning events. I have come up with a number of different potential policy statements on when backwards compatibility should be broken and when it should be kept. It might help us to reach consensus if members of the CellML community could rank the policies in order of preference (1 is the most preferable policy, 2 the next most, and so on), and suggest any good policies that may be missing. Option A) Future versions of CellML should aim to solely express the intention of previous versions better and more clearly. They should aim to keep full compatibility with an implementation of the specification according to the rules of the specification as they were interpreted by implementors. Option B) Future versions of CellML should try to be mostly compatible with existing implementations of previous versions of CellML. They may remove functionality that does not have an established base of software which correctly implements that functionality. They may also add in new functionality, if that new functionality significantly increases the expressiveness of the language. However, in normal circumstances, compatibility should be maintained, so that when a model not using new features is saved in the new version's most preferred format, it can still be correctly loaded into software only supporting the old version. Likewise, a model not using any removed features should be able to be loaded in software supporting only the new version of the specification. Option C) Future versions of CellML should make any changes which make it conceptually cleaner, even if there is a less clean compromise available that would have lesser compatibility implications. Software will need to explicitly support more than one version as a completely separate format. My preferred choice is Option B. Despite being apparently at opposite ends of the spectrum, Option A and Option C are, in my opinion, fairly similar, because if we adopted Option A, larger changes would appear in a new specification called something other than CellML. Although there could be advantages of coming up with a more meaningful name than CellML, I think that this would also set us back in terms of community awareness of the specification, and so I think that Option C is marginally better than Option A (i.e. my personal order of preference is currently B:1, C:2, A:3). I would have to concur - out of those three possibilities, B would be preferable. Kind regards, James I look forward to any feedback on this you may have. Best regards, Andrew ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion begin:vcard fn:James Lawson n:Lawson;James org:Auckland Bioengineering Institute;CellML Model Repository Curator, CellML Team adr:;;University of AucklandNew Zealand email;internet:[EMAIL PROTECTED] title:James Lawson url:http://www.cellml.org version:2.1 end:vcard ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Survey on opinions for the backwards compatibility levels for future CellML Specs
Poul Nielsen wrote: > I think that the best policy is to evolve CellML toward a clean and > simple specification. I don't think that this means that we require a > complete break with previous specifications at each major iteration > if, for example, we use deprecated/obsolescent flags. I believe that > it is essential, however, that we provide a mechanism for adding and, > importantly, removing elements and attributes. > I agree that there are circumstances when elements and attributes can be added or removed. However, the impact of this depends greatly on which elements are being added or removed. > We have discussed previously the option of retaining deprecated/ > obsolescent elements/attributes for one or several iterations with a > view to maintain compatibility, but signaling that more appropriate > constructs are available and that such features are marked for > deletion. Examples of what is at issue here are suggestions that (1) > the reaction element be removed This fits into the category of changes which would probably not have a major impact on the current software base, because (as far as I know) there are no tools that implement reaction correctly at present. This is contrasted with a tangible benefit to removing reactions, specifically, that compliant software does not need to implement it (and historically this has been a cause of deviation from the specification). > and (2) the public_interface and > private_interface elements be removed or their attributes be > modified. This latter case, on the other hand, fits into the category of changes which would break every single existing CellML 1.1 model and force it to be regenerated for CellML 1.2. I see this as having a much greater impact than removing reactions. On the other hand, while the directionality on interfaces is unnecessary, it is not a huge implementation burden - we could just maintain directionality as a historical quirk of CellML. I think it is a question of taking a pragmatic vs an idealistic strategy. The idealistic strategy is to break compatibility on even the most simple models to clean up the specification, while the pragmatic approach will try to balance compatibility against specification improvement. I would argue that for the best strategy for the long term future of CellML is to be somewhat pragmatic, and try to avoid forcing every single model to recoded. I think that this approach is also very common as programming languages evolve. For example, programs can be written which are valid in FORTRAN90 and FORTRAN77. Most valid FORTRAN77 programs would be valid FORTRAN90 programs, although there are some F77 programs which are not valid F90 programs. If you wrote a program in F90 and didn't use any F90 features, it should be a valid F77 program. Likewise, a similar situation can be seen with the various revisions of C++ (and even between C and C++). > Deprecation has the advantage of offering a more gentle > transition, allowing models expressed in older, but not every, > iteration specification to be interpreted. It has the disadvantage > that it may not provide a clean break, making it difficult to deal > with the addition of new features that may be incompatible with old > ones. In both scenarios it will be important to provide tools to > translate older models into newer versions that conform to later > specifications. > > Because I think that it is important to be able to remove elements/ > attributes, I am not in favour of option A. Like Mike, I have a > problem with the statement that "[future versions] may remove > functionality that does not have an established base of software > which correctly implements that functionality". If the addition or > removal of elements or attributes results in a better specification, > then I think that consideration should be made for such changes > irrespective of whether there is "an established base of software > which correctly implements that functionality". Although the same argument could be used, for example, to suggest that C++ should clean up the exceptions or any of several other well documented syntactic issues which C++ has inherited from early versions or from C, and yet the committees for these languages tend to avoid changes which break compatibility too much. While CellML isn't exactly a programming language, I think we should probably take note of the way they handle compatibility. > My preferred option > is C, with the proviso that translation tools and APIs, conforming to > the new specification, be made available at the time of transition. > I think that realistically, tools will take time to develop, and although we could go through an extended draft phase as we have done in the past, people will use the new format as soon as tools support it, and we should probably try to minimise the level of incompatibility this causes (subject to our need to add
Re: [cellml-discussion] Survey on opinions for the backwards compatibility levels for future CellML Specs
I think that the best policy is to evolve CellML toward a clean and simple specification. I don't think that this means that we require a complete break with previous specifications at each major iteration if, for example, we use deprecated/obsolescent flags. I believe that it is essential, however, that we provide a mechanism for adding and, importantly, removing elements and attributes. We have discussed previously the option of retaining deprecated/ obsolescent elements/attributes for one or several iterations with a view to maintain compatibility, but signaling that more appropriate constructs are available and that such features are marked for deletion. Examples of what is at issue here are suggestions that (1) the reaction element be removed and (2) the public_interface and private_interface elements be removed or their attributes be modified. Deprecation has the advantage of offering a more gentle transition, allowing models expressed in older, but not every, iteration specification to be interpreted. It has the disadvantage that it may not provide a clean break, making it difficult to deal with the addition of new features that may be incompatible with old ones. In both scenarios it will be important to provide tools to translate older models into newer versions that conform to later specifications. Because I think that it is important to be able to remove elements/ attributes, I am not in favour of option A. Like Mike, I have a problem with the statement that "[future versions] may remove functionality that does not have an established base of software which correctly implements that functionality". If the addition or removal of elements or attributes results in a better specification, then I think that consideration should be made for such changes irrespective of whether there is "an established base of software which correctly implements that functionality". My preferred option is C, with the proviso that translation tools and APIs, conforming to the new specification, be made available at the time of transition. Best wishes Poul On 2008 Jan 09, at 11:58, Andrew Miller wrote: > Hi all, > > There have recently been some discussions of changes which would > drastically break forwards or backwards compatibility of CellML (for > example, changing the way that connections work). > > I think that it is important that we come to some consensus on what > the > policy for inter-version compatibility in CellML should be quite soon, > because this drastically affects decisions that need to be made in > CellML specification development. > > It doesn't really make sense to be inconsistent with respect to > version > compatibility - it would be quite unfortunate if we worked hard to > keep > compatibility for one part of CellML, and then broke it in another > major > part such as by changing the way connections work, and so I think we > need a policy on this. > > I have come up with a number of different potential policy > statements on > when backwards compatibility should be broken and when it should be > kept. It might help us to reach consensus if members of the CellML > community could rank the policies in order of preference (1 is the > most > preferable policy, 2 the next most, and so on), and suggest any good > policies that may be missing. > > Option A) > Future versions of CellML should aim to solely express the > intention of > previous versions better and more clearly. They should aim to keep > full > compatibility with an implementation of the specification according to > the rules of the specification as they were interpreted by > implementors. > > Option B) > Future versions of CellML should try to be mostly compatible with > existing implementations of previous versions of CellML. They may > remove > functionality that does not have an established base of software which > correctly implements that functionality. They may also add in new > functionality, if that new functionality significantly increases the > expressiveness of the language. However, in normal circumstances, > compatibility should be maintained, so that when a model not using new > features is saved in the new version's most preferred format, it can > still be correctly loaded into software only supporting the old > version. > Likewise, a model not using any removed features should be able to be > loaded in software supporting only the new version of the > specification. > > Option C) > Future versions of CellML should make any changes which make it > conceptually cleaner, even if there is a less clean compromise > available > that would have lesser compatibility implications. Software will > need to > explicitly support more than one version as a completely separate > format. > > My preferred choice is Option B. Despite being apparently at opposite > ends of the spectrum, Option A and Option C are, in my opinion, fairly > similar, because
Re: [cellml-discussion] Survey on opinions for the backwards compatibility levels for future CellML Specs
If I had to choose one I'd go B. I am concerned about words like 'mostly' - it should be clear whether it means mostly compatible in a given versioning instance or mostly as in across versioning instances, or both. If you are talking strict policy then I suspect by default you want to maintain backwards compatibility but also there may be times when a clean break in compatibility is desirable. I think the tradeoffs between clean breaks and the amount of software relying on a to-be-broken feature are matters for the cellml oversight team and should not be bound in policy. Hence I would remove the statement: " They may remove functionality that does not have an established base of software which correctly implements that functionality." It is too restrictive. As a general comment I think these kind of decisions are more about future market, features and resource constraints that cannot be determined in advance and should not be embodied in some kind of policy. Can I suggest making it a 'guideline' so that the appropriate issues are raised (as they should be) but do not necessarily restrict fulfilling strategic imperatives. My 2c, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Miller Sent: Wednesday, 9 January 2008 11:59 a.m. To: For those interested in contributing to the development of CellML. Subject: [cellml-discussion] Survey on opinions for the backwards compatibility levels for future CellML Specs Hi all, There have recently been some discussions of changes which would drastically break forwards or backwards compatibility of CellML (for example, changing the way that connections work). I think that it is important that we come to some consensus on what the policy for inter-version compatibility in CellML should be quite soon, because this drastically affects decisions that need to be made in CellML specification development. It doesn't really make sense to be inconsistent with respect to version compatibility - it would be quite unfortunate if we worked hard to keep compatibility for one part of CellML, and then broke it in another major part such as by changing the way connections work, and so I think we need a policy on this. I have come up with a number of different potential policy statements on when backwards compatibility should be broken and when it should be kept. It might help us to reach consensus if members of the CellML community could rank the policies in order of preference (1 is the most preferable policy, 2 the next most, and so on), and suggest any good policies that may be missing. Option A) Future versions of CellML should aim to solely express the intention of previous versions better and more clearly. They should aim to keep full compatibility with an implementation of the specification according to the rules of the specification as they were interpreted by implementors. Option B) Future versions of CellML should try to be mostly compatible with existing implementations of previous versions of CellML. They may remove functionality that does not have an established base of software which correctly implements that functionality. They may also add in new functionality, if that new functionality significantly increases the expressiveness of the language. However, in normal circumstances, compatibility should be maintained, so that when a model not using new features is saved in the new version's most preferred format, it can still be correctly loaded into software only supporting the old version. Likewise, a model not using any removed features should be able to be loaded in software supporting only the new version of the specification. Option C) Future versions of CellML should make any changes which make it conceptually cleaner, even if there is a less clean compromise available that would have lesser compatibility implications. Software will need to explicitly support more than one version as a completely separate format. My preferred choice is Option B. Despite being apparently at opposite ends of the spectrum, Option A and Option C are, in my opinion, fairly similar, because if we adopted Option A, larger changes would appear in a new specification called something other than CellML. Although there could be advantages of coming up with a more meaningful name than CellML, I think that this would also set us back in terms of community awareness of the specification, and so I think that Option C is marginally better than Option A (i.e. my personal order of preference is currently B:1, C:2, A:3). I look forward to any feedback on this you may have. Best regards, Andrew ___ 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/cellm
[cellml-discussion] Survey on opinions for the backwards compatibility levels for future CellML Specs
Hi all, There have recently been some discussions of changes which would drastically break forwards or backwards compatibility of CellML (for example, changing the way that connections work). I think that it is important that we come to some consensus on what the policy for inter-version compatibility in CellML should be quite soon, because this drastically affects decisions that need to be made in CellML specification development. It doesn't really make sense to be inconsistent with respect to version compatibility - it would be quite unfortunate if we worked hard to keep compatibility for one part of CellML, and then broke it in another major part such as by changing the way connections work, and so I think we need a policy on this. I have come up with a number of different potential policy statements on when backwards compatibility should be broken and when it should be kept. It might help us to reach consensus if members of the CellML community could rank the policies in order of preference (1 is the most preferable policy, 2 the next most, and so on), and suggest any good policies that may be missing. Option A) Future versions of CellML should aim to solely express the intention of previous versions better and more clearly. They should aim to keep full compatibility with an implementation of the specification according to the rules of the specification as they were interpreted by implementors. Option B) Future versions of CellML should try to be mostly compatible with existing implementations of previous versions of CellML. They may remove functionality that does not have an established base of software which correctly implements that functionality. They may also add in new functionality, if that new functionality significantly increases the expressiveness of the language. However, in normal circumstances, compatibility should be maintained, so that when a model not using new features is saved in the new version's most preferred format, it can still be correctly loaded into software only supporting the old version. Likewise, a model not using any removed features should be able to be loaded in software supporting only the new version of the specification. Option C) Future versions of CellML should make any changes which make it conceptually cleaner, even if there is a less clean compromise available that would have lesser compatibility implications. Software will need to explicitly support more than one version as a completely separate format. My preferred choice is Option B. Despite being apparently at opposite ends of the spectrum, Option A and Option C are, in my opinion, fairly similar, because if we adopted Option A, larger changes would appear in a new specification called something other than CellML. Although there could be advantages of coming up with a more meaningful name than CellML, I think that this would also set us back in terms of community awareness of the specification, and so I think that Option C is marginally better than Option A (i.e. my personal order of preference is currently B:1, C:2, A:3). I look forward to any feedback on this you may have. Best regards, Andrew ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
