Hi all,

I have recently been working on developing an unofficial 'base' 
normative CellML specification to provide something off which proposed 
changes can be based and merged into.

The aim of this unofficial draft specification is to provide a 
minimalistic, and normative, specification of all the core functionality 
of CellML. It aims to correct ambiguities and contradictions from within 
the CellML 1.1 specification (and without reactions, simply because it 
wasn't worth adding them to this spec unless the consensus seems to 
indicate we might keep them).

The specification as it stands now (which can be obtained from my public 
git repository, using the instructions previously posted, or viewed at 
) needs more careful review of the following aspects:
  1) Does the specification lose any important normative information 
that CellML 1.1 includes?
  2) Is there any part of the specification that can be interpreted in 
more than one way (i.e. ambiguities)? I have been aiming to be very 
strict about removing alternative interpretations so there is no 
reliance on common sense to guess what the text means - this is the only 
way to ensure that there are no disputes about what the specification 
means, and so it would be good to fix even trivially obvious ambiguities.

Known deviations from 1.1

1) Reactions are not described, deliberately.
2) The name attribute on group has not been described. There are 
discussion underway about what to do with group - if only encapsulation 
is allowed, we can simplify it and get rid of name, otherwise we may 
need to re-add it.
3) The meaning of attributes without explicit namespace prefixes was 
defined in 1.1 to override the XML Specification. This had to be removed 
to prevent a conflict between the namespaces in XML normative reference 
and the specification text.
4) There is nothing in the specification corresponding to the 
restrictions on group in CellML 1.1 section bullet point 2. The 
reason is that this is somewhat problematic when applied across imports, 
and the assertion in CellML 1.1 that having multiple group elements 
makes processing more complex has not been shown to be true in 
implementation experience (while testing the rule does make things more 
5) The restriction that grouping hierarchies must form a tree is only 
specified for the encapsulation. This could be extended to all groups if 
we decide to keep groups.
6) There are no restrictions on duplicate connection elements for the 
same pair of components (but there are for duplicate connections to the 
same variables).

Best regards,

cellml-discussion mailing list

Reply via email to