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
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
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
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
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
