CellML Discussion List

Text archives Help


[cellml-discussion] Unofficial draft CellML specification - backwards compatibility, type attributes on variables


Chronological Thread 
  • From: ak.miller at auckland.ac.nz (Andrew Miller)
  • Subject: [cellml-discussion] Unofficial draft CellML specification - backwards compatibility, type attributes on variables
  • Date: Wed, 09 Feb 2011 13:39:02 +1300

On 02/02/11 18:36, Lucian Smith wrote:
> * Andrew Miller<ak.miller at auckland.ac.nz> [2011-02-02 03:27] writes:
>> Hi all,
>>
>> I've just put up an unofficial draft CellML specification up at
>> http://www.cellml.org/Members/miller/draft-normative-spec-andrews-preferred/toplevel.xhtml
>> to prototype what some of the new features could look like.
>>
>> This version has the following features:
>> Backwards and forwards compatibility with CellML 1.1.
>> A new attribute, type, on variables. It defaults to real, but can
>> alternatively point to a URL defining the type (it is up to secondary
>> specifications to define the meaning of URLs other than the one for real
>> values defined in the specification).
>>
>> The source for generating the specification and creating your own draft
>> version is up at http://repo.or.cz/w/cellml-draft-miller.git - the
>> andrews-preferred-version branch was used to generate the XHTML linked to.
>
> The section on MathML was a little vague--are *all* valid MathML
> constructs valid CellML constructs, or only a subset?

Hi all,

All valid MathML constructs are, under the draft, valid according to
that draft if they occur in the correct part of the model. The
specification allows secondary specifications to be defined which narrow
down CellML models to a set which can be implemented by a solver in
their entirety.

>
> Also, I didn't see anything in there about events--are those being
> deferred again?

This is not a final draft, it is an unofficial one to add specific
things to previous drafts.

Supporting the same types of models that 'events' would support was one
of the motivations for adding the type attribute - it is likely that not
much else is needed in the primary specification. Events can essentially
be supported as mathematical expressions - either using piecewise or
logical operators, combined with an infinitesimal delay (a csymbol -
something that would be defined in a secondary specification).

For example, to halve x when it gets to 20, the mathematics might look like:
(infinitesimallyDelayed(x) < 20) or (x = infinitesimallyDelayed(x) / 2)

Like all equations in the model, this is an assertion. In this case, it
is that either x was less than 20 an instant before now, or x is now
half of what it was before. This declarative form could be converted
into an imperative form (assign to x if it ever becomes less than 20) by
tools.

>
> My only other suggestion is that eventually you'll want pictures in there
> ;-)

The intention is to make a normative specification, containing only the
formal description of CellML, with has no extraneous material, as the
authoritative specification, and an informative one based on that, which
would not be the authoritative, but would be easier to read.

Best wishes,
Andrew

>
> -Lucian
> _______________________________________________
> 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