On 03/07/12 11:34, Lucian Smith wrote:
I have one comment:

* Andrew Miller<ak.mil...@auckland.ac.nz>  [2012-07-03 00:07] writes:
   2. Should CellML 1.2 be an incremental change over CellML 1.1, with
another version planned shortly after, or should it try to incorporate a
wider set of changes? (target: 9:05 - 9:25)
This strikes me as being the wrong question.  Instead I would ask, "What
do we want to accomplish with CellML that cannot be accomplished with
1.1?"  Then you look at the list of things you came up with, and classify
each into 'would be a small change' vs. 'would be a large change'.  Then,
finally, you look at the list of small changes and decide whether it's
worth it to have a release with just those changes vs. the whole list.  I
would think the MathML 3.0 question would fall out of this discussion,
too, rather than having to be a separate agenda item.
I would think that this could be part of the discussion, but not the whole discussion.

If the plan was to make the smallest possible incremental set of changes, then it absolutely would make sense to only change things if they currently impose a hard constraint on what can be modelled in CellML.

However, for CellML to be more useful, it needs wider tool support and a wider collection of available models, which means it needs a wider community. To expand the CellML community, barriers to community uptake need to be addressed. One barrier might be that people want to create types of models that cannot currently be represented in CellML. However, an even larger barrier is likely to be the complexity of implementing CellML and the ambiguities in its specification. Therefore, changes to the design which simplify the language, make it less ambiguous and more interoperable and extensible could be very important, even if they don't directly expand the range of models which can be represented in CellML.

Therefore, there are two competing approaches:
1. smallest possible change set to represent additional types of models we want to represent. 2. redesigning the language so that it is cleaner and more extensible, with the extensibility mechanisms meaning it might be a long time before we need to do another major compatibility breaking redesign.

I personally think that if 1 is going to break backwards compatibility anyway, we would be better off doing 2, and developing tools to convert between the new redesigned language and the old one.

Best wishes,

cellml-discussion mailing list

Reply via email to