Alan Garny wrote:
> Dear Andrew,
>
> I quite like the structure of your document. Just one thing though: I would
> like, at this stage, to suggest references to the official CellML
> specification.
Hi Alan,

I am not quite sure I follow where you are proposing that the references 
should actually be from. Are you suggesting that the draft  for the new 
version of CellML should refer to the previous one? Remember that this 
is a normative draft, and so it can only have normative references. A 
normative reference to the CellML 1.1 specification wouldn't seem 
appropriate for a CellML 1.2 specification - it would then include 1.1 
by reference and bring back all the problems associated with CellML 1.1. 
I think that a point-by-point annotation of the specification to 
contrast it with CellML 1.1 could be a valuable 'informative' part of 
the specification - it would be purely informative and wouldn't alter 
the meaning of the specification. However, the inclusion of this 
informative material is not part of the goals of creating the initial 
normative specification - rather, the aim is to very clearly separate 
the normative material from the informative material to aid in making 
the specification unambiguous.

Best regards,
Andrew

>  Indeed, you are no doubt very familiar with the official
> CellML specification, but in my case it has been years since I have had a
> proper look at it. So, it would help me (and others, I am sure!) if you
> could put some references here and there. That would 1) encourage people to
> give you feedback and 2) would save those of us (who are willing to provide
> you with some feedback) a lot of time.
>
> Best wishes, Alan.
>
>   
>> -----Original Message-----
>> From: [EMAIL PROTECTED] [mailto:cellml-discussion-
>> [EMAIL PROTECTED] On Behalf Of Andrew Miller
>> Sent: 16 January 2008 23:30
>> To: For those interested in contributing to the development of CellML.
>> Subject: [cellml-discussion] Base normative CellML Specification for
>> further work
>>
>> 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
>>     
>
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion
>   

_______________________________________________
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Reply via email to