Chronological Thread 

< Chronological >      < Thread >

---

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
http://www.cellml.org/Members/miller/draft-normative-spec-allow-secondary/toplevel.xhtml
).

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,
Andrew

---

• [cellml-discussion] Proposal: Secondary specifications in CellML, Andrew Miller, 01/30/2008

---

Archive powered by MHonArc 2.6.18.