Chronological Thread 

< Chronological >      < Thread >

---

On 03/07/12 11:34, Lucian Smith wrote:
> I have one comment:
>
> * Andrew Miller<ak.miller at 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] Auckland CellML Meeting planned for Wednesday July 4th from 9-10 AM (NZST), Andrew Miller, 07/03/2012
  • [cellml-discussion] Auckland CellML Meeting planned for Wednesday July 4th from 9-10 AM (NZST), Lucian Smith, 07/03/2012
    • [cellml-discussion] Auckland CellML Meeting planned for Wednesday July 4th from 9-10 AM (NZST), Andrew Miller, 07/03/2012

---

Archive powered by MHonArc 2.6.18.