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 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 >> [email protected] >> http://www.cellml.org/mailman/listinfo/cellml-discussion > > _______________________________________________ > cellml-discussion mailing list > [email protected] > http://www.cellml.org/mailman/listinfo/cellml-discussion -- David Nickerson, PhD Research Fellow Division of Bioengineering Faculty of Engineering National University of Singapore Email: [EMAIL PROTECTED] _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
