Chronological Thread 

< Chronological >      < Thread >

---

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
>> cellml-discussion at cellml.org
>> http://www.cellml.org/mailman/listinfo/cellml-discussion
>
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

--
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: david.nickerson at nus.edu.sg

---

• [cellml-discussion] Survey on opinions for the backwards compatibility levels for future CellML Specs, Andrew Miller, 01/09/2008
  • [cellml-discussion] Survey on opinions for the backwards compatibility levels for future CellML Specs, Mike Cooling, 01/09/2008
  • [cellml-discussion] Survey on opinions for the backwards compatibility levels for future CellML Specs, Poul Nielsen, 01/09/2008
    • [cellml-discussion] Survey on opinions for the backwards compatibility levels for future CellML Specs, Andrew Miller, 01/09/2008
      • [cellml-discussion] Survey on opinions for the backwards compatibility levels for future CellML Specs, Poul Nielsen, 01/10/2008
        • [cellml-discussion] Survey on opinions for the backwards compatibility levels for future CellML Specs, Randall Britten, 01/10/2008
          • [cellml-discussion] Survey on opinions for the backwards compatibility levels for future CellML Specs, James Lawson, 01/11/2008
    • [cellml-discussion] Survey on opinions for the backwardscompatibility levels for future CellML Specs, David Nickerson, 01/09/2008
  • [cellml-discussion] Survey on opinions for the backwards compatibility levels for future CellML Specs, James Lawson, 01/09/2008
    • [cellml-discussion] Survey on opinions for the backwards compatibility levels for future CellML Specs, Andrew Miller, 01/09/2008

---

Archive powered by MHonArc 2.6.18.