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 mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
