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 http://www.cellml.org/Members/miller/draft-normative-spec/toplevel.xhtml ) 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 6.4.3.2 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 complex). 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, Andrew _______________________________________________ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
