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: m.cooling at auckland.ac.nz (Mike Cooling)
  • Subject: [cellml-discussion] Survey on opinions for the backwards compatibility levels for future CellML Specs
  • Date: Wed, 9 Jan 2008 12:21:29 +1300
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: cellml-discussion-bounces at cellml.org
[mailto:cellml-discussion-bounces at cellml.org] 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 at cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion



Archive powered by MHonArc 2.6.18.

Top of page