CellML Discussion List

Text archives Help


[cellml-discussion] CellML 1.2 and MathML 3


Chronological Thread 
  • From: david.nickerson at gmail.com (David Nickerson)
  • Subject: [cellml-discussion] CellML 1.2 and MathML 3
  • Date: Wed, 13 Jun 2012 13:37:30 +1200

Hi Andrew,

Thanks for your input. I have a couple of comments that are relevant here.

Firstly, as noted on tracker item 55 for CellML 1.2, the editorial
board is just starting on the process of establishing what changes and
additions will go into CellML 1.2. Please don't view the current state
of tracker items 55
(https://tracker.physiomeproject.org/show_bug.cgi?id=55) and 2886
(https://tracker.physiomeproject.org/show_bug.cgi?id=2886) as final or
in any way set in concrete. The editorial board will announce the
proposed "changeset" for CellML 1.2 once we have it sorted. Part of
such an announcement will be setting out our reasons for the proposed
changes and an invitation for community discussion.

Secondly, as noted previously, the editorial board decided that it
would be best to make CellML 1.2 a relatively minor incremental
release beyond 1.1 in terms of the feature set of the CellML standard
but one which moves us in a direction better suited to future
evolution of the specification. Given such an approach, it is hard to
see how a fundamental change to such a core part of CellML would fit
into CellML 1.2. Hence the current location of MathML 3 under the
future versions rather than specifically 1.2. As noted above, this is
not set in concrete and the editorial board is considering all the
implications of the proposals under both tracker item 55 and 2886. I
would hope that with the release of 1.2 we will be in a position begin
the development of CellML 1.3 (or perhaps 2.0) relatively quickly (at
least at a pace much more rapid than historically shown for previous
versions of CellML).

Finally, it would be best for any specific justifications for the
adoption of specific proposals be added to the tracker item for the
proposal in order to best capture the information in a convenient
location for all to discuss.


Cheers,
Andre.


On Wed, Jun 13, 2012 at 1:05 PM, Andrew Miller <ak.miller at auckland.ac.nz>
wrote:
> Hi,
>
> I'd like to suggest that using MathML 3 rather than MathML 2 be considered
> in the work to develop CellML 1.2; it is currently in the tracker as an item
> for future versions of CellML. I believe my proposal is well justified for
> the following reasons:
>
> 1. MathML 3 is more mathematically sound than MathML 2. MathML 2 relies on a
> number of poorly documented conventions, and has built in operators that are
> not very comprehensively defined. On the other hand, MathML 3 has two forms,
> strict and non-strict, with well-defined rules for translating from
> non-strict to strict form, and with every symbol in strict form mapping to
> an OpenMath content dictionary to give it mathematical meaning.
>
> 2. The semantics for extending MathML 3 are cleaner are more consistent -
> you use an existing OpenMath content dictionary that covers what you want,
> or define a new content dictionary.
>
> 3. The drafts that I put together (up at
> http://www.cellml.org/Members/miller/draft-secondary-spec-dae-events/toplevel.xhtml)
> are based on the assumption that MathML 3 will be used, as are the draft
> secondary specifications. For example, they refer to content dictionaries.
> This allows for certain things to be defined very easily in the secondary
> specifications, without the need to spell out things like the type semantics
> of operators. For example, my secondary specification draft for models with
> DAEs with events spells out which OpenMath STS types correspond to the
> CellML real type and which ones correspond to boolean, and refers to classes
> of allowed operators by referring to particular content dictionaries. Having
> to repeat all this information explicitly would make secondary
> specifications considerably more messy.
>
> 4. An effort to prototype my CellML 1.2 draft is well under way (code at
> https://github.com/A1kmm/cellml-testbed). This effort is based on MathML 3.
> Implementation experience helps to verify that a draft standard is feasible,
> because the process of implementation can identify issues with a
> specification. There is no corresponding implementation experience that
> combines the other proposed CellML 1.2 changes with MathML 2.
>
> Best wishes,
> Andrew
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion at cellml.org
> http://lists.cellml.org/mailman/listinfo/cellml-discussion




Archive powered by MHonArc 2.6.18.

Top of page