First login?
Lost password?
 
 
cellml-discussion AT lists.cellml.org 
CellML Discussion List

Text archives Help


[cellml-discussion] Survey on opinions for the backwards compatibility levels for future CellML Specs


Chronological Thread 
  • From: j.lawson at auckland.ac.nz (James Lawson)
  • Subject: [cellml-discussion] Survey on opinions for the backwards compatibility levels for future CellML Specs
  • Date: Wed, 09 Jan 2008 15:35:40 +1300
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 at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: j_lawson.vcf
Type: text/x-vcard
Size: 278 bytes
Desc: not available
Url :
http://www.cellml.org/pipermail/cellml-discussion/attachments/20080109/287c64e6/attachment-0001.vcf



Archive powered by MHonArc 2.6.18.

Top of page