Hi all,

I am proposing that we define CellML 1.2 such that 'secondary CellML 
specifications' can be created. The primary CellML 1.2 specification 
will then define the core structure of CellML and the semantics of how 
models are created, with the secondary specifications narrowing it down 
to specific types of problems.

In CellML 1.1, there are several mechanisms equivalent to this in operation:
  1) The core 1.1 specification defines a 'CellML Subset'. This is not 
mandatory, and because there are useful operators like rem not on the 
list, neither models nor software has limited support to items on the 
list (which argues for putting such restrictions outside of the core 
specification, where updated secondary specifications can be made 
without going through the process of making an update to the primary 
specification). Furthermore, the specification doesn't describe, in 
enough detail, about how the exact types of mathematical constructs 
which are allowed. With the secondary specifications, we don't need a 
CellML Subset in the primary specification.
  2) The examples in the CellML 1.1 Specification allow a kind of 
'learning by example' about how the mathematics should be written. This 
is not very good from a specification point of view - we should describe 
precisely what is and is not allowed rather than require tool developers 
to infer this information from examples.
  3) I have previously proposed a 'Best Current Practice' for CellML 1.1 
mathematics (http://www.cellml.org/Members/miller/bcp-toplevel-maths/). 
Creating specification-endorsed formal secondary specifications extends 
this approach and removes any doubt that implementors which cannot, for 
whatever reason, support the entire primary specification, instead need 
to pick (or define) a secondary specification to specify the problem 
type the software can solve.

I wrote up a very simplistic, but I think workable, example of the delegating
text. My version is in git://repo.or.cz/srv/git/cellml-draft-miller.git branch
allow-secondary (also viewable at

CellML Processing Software is required (i.e. the use of the specification word
MUST) either support one or more specific secondary specifications, or support
every single possible CellML model. In practice, editing software may want to
take the latter option because they can, while simulation software will have no
choice but to limit support to particular well-defined classes of problems.

There is a tracker item in the tracker at 
https://tracker.physiomeproject.org/show_bug.cgi?id=332 about this - if 
you want to be kept updated on this, then you can visit the URL, create 
a tracker account if you don't have one yet, and add yourself to the CC 
list for the tracker item.

Best regards,

cellml-discussion mailing list

Reply via email to