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: p.nielsen at auckland.ac.nz (Poul Nielsen)
  • Subject: [cellml-discussion] Survey on opinions for the backwards compatibility levels for future CellML Specs
  • Date: Wed, 9 Jan 2008 13:57:44 +1300
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
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion



Archive powered by MHonArc 2.6.18.

Top of page