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,
Andrew
_______________________________________________
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion
