Chronological Thread 

< Chronological >      < Thread >

---

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] Base normative CellML Specification for further work, Andrew Miller, 01/17/2008
  • [cellml-discussion] Base normative CellML Specification for further work, Alan Garny, 01/17/2008
    • Message not available
      • [cellml-discussion] Base normative CellML Specification for further work, Andrew Miller, 01/18/2008
    • [cellml-discussion] Base normative CellML Specification for further work, Andrew Miller, 01/18/2008
      • [cellml-discussion] Base normative CellML Specificationfor further work, David Nickerson, 01/18/2008
      • [cellml-discussion] Base normative CellML Specification for further work, alan.garny at dpag.ox.ac.uk, 01/18/2008

---

Archive powered by MHonArc 2.6.18.