Re: [cellml-discussion] Base normative CellML Specification for further work
Hi Andrew, > 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. All I was suggesting was a way to make it easier for people to give you feedback. One possible way, in my opinion, would be to make references to the current CellML 1.1 specification. Such information could be removed before releasing the final version of your document (or leave it as annotations). I have no problem with that, it's just that I believe it would help us to help you (so to speak!). Best regards, Alan. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
[cellml-discussion] Auckland CellML Group Meeting Minutes (2008-01-16)
Greetings, The minutes of the Auckland CellML group meeting of 2008-01-16 can now be found at: http://www.cellml.org/meeting_minutes/latest Kind Regards, Tommy. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Base normative CellML Specificationfor further work
I think Andrew is correct and having a purely normative specification is the way we ought to be going. However, as Alan points out, the annotated informative version of the specification will be a useful tool in the evaluation and development of the next version of CellML. Which leads to the question of whether anyone is working on the informative version or if anyone has thought about the best way the informative version could be developed in conjunction with the normative specification. However it goes, I think its important that the informative version is developed closely alongside the normative. Andre. Andrew Miller wrote: > 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
Re: [cellml-discussion] Base normative CellML Specification for further work
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-discuss
Re: [cellml-discussion] Base normative CellML Specification for further work
Randall Britten wrote: > 18.3 point 9 defines the hidden set for a *component*. 18.4 point 6 refers > to the hidden set of a *variable*. > > Similar for encapsulated set and sibling set. > > Might be OK as is, but what do you think? > Thanks Randall, this is exactly the type of issue we need to identify and fix, and I really appreciate your help in finding these types of issues. I have pushed a fix for this to my public git repo, and also put it up on my 'latest rendered version of the spec' page. One thing this raises is how we refer to parts of other people's drafts - once we have a stable specification, it will be very convenient to say things like 18.3.9, but the problem with drafts is that the numbers are changing all the time and adding or removing a section would renumber everything. We could refer to a particular git commit id together with a number, e.g. 18.3.9 at commit ac9c214d5ff051229bda8f4668430cc09c3488ef (http://repo.or.cz/r/cellml-draft-miller.git). However, a simpler low-tech approach might be to just quote the surrounding text so people can search for it. Best regards, Andrew > >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:cellml-discussion- >> [EMAIL PROTECTED] On Behalf Of Alan Garny >> Sent: Thursday, 17 January 2008 10:52 p.m. >> To: 'CellML Discussion List' >> Subject: Re: [cellml-discussion] Base normative CellML Specification >> for further work >> >> 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. 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 pr
Re: [cellml-discussion] Base normative CellML Specification for further work
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. 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
