CellML Discussion List

Text archives Help


[cellml-discussion] Solicitation of feedback on CellML 1.2


Chronological Thread 
  • From: ak.miller at auckland.ac.nz (Andrew Miller)
  • Subject: [cellml-discussion] Solicitation of feedback on CellML 1.2
  • Date: Mon, 05 Nov 2012 16:43:53 +1300

On 05/11/12 10:10, Jonathan Cooper wrote:
> Hi all,
>
> Just wanted to respond to a couple of points.
>
> On 30/10/2012 02:53, Andrew Miller wrote:
>> On 29/10/12 22:36, David Nickerson wrote:
>>> In addition, we specifically ask for feedback on the issue of moving to
>>> MathML 3.0 (tracker item 67
>>> <https://tracker.physiomeproject.org/show_bug.cgi?id=67>) and the
>>> inclusion of stochastic variation in models (tracker item 2809
>>> <https://tracker.physiomeproject.org/show_bug.cgi?id=2809>). The
>>> editors
>>> generally agree that switching to MathML 3.0 at this time provides too
>>> little benefit (mathematical clarity) for the cost involved in making
>>> the change (tool support, interoperability with other exchange
>>> formats).
>>
>> I think that it would be worth including MathML 3.0 in CellML 1.2
>> because:
>> 1. It makes implementation easier by providing clear rules about
>> the mathematical interpretation of models.
>> 2. It is more cleanly extensible through the use of OpenMath
>> content dictionaries.
>> 3. It is mostly forwards and backwards compatible with MathML 2.0 -
>> nearly every MathML 2.0 expression is valid MathML 3.0, and you can
>> write MathML 3.0 so it is valid MathML 3.0.
>> 4. The only implementation of the CellML 1.2 proposals so far has
>> already been coded to use MathML 3.0 - so the cost in terms of tool
>> support so far would actually be higher to change that implementation
>> to support MathML 2.0.
>
> For the sake of those not at the ABI, could you give more details of
> this implementation? Is it an API library that can be used from
> multiple programming languages?

The implementation is intended as a demonstration of CellML 1.2
features, and so design decisions have primarily focused on minimising
development costs and maintaining agility rather than providing the best
possible interface.

It is written in Haskell, but with the work currently being completed,
limited C++ bindings to access generated code and run simulations will
also be available.

Best wishes,
Andrew





Archive powered by MHonArc 2.6.18.

Top of page