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

Reply via email to