Re: [cellml-discussion] CellML 1.1.1 specification

2007-07-19 Thread Alan Garny
If we had our specification in a version control system and tagged out releases and release candidates etc, and if we followed a protocol of releasing at least one stable minor release that marks depreciation only, then the following would be the result (in my mind) - The current

Re: [cellml-discussion] CellML 1.1.1 specification

2007-07-19 Thread James Lawson
David Nickerson wrote: Matt wrote: It seems there is some misunderstanding as to whether we are discussing a proposal to remove the reaction element from CellML or a proposed new specification. I thought it was the latter but you seem to be talking about the former... Both. I think. So I

Re: [cellml-discussion] CellML 1.1.1 specification

2007-07-19 Thread Matt
More generally I think this issue is tapping on the bigger issue of a core modelling language and specification, and then special use cases, of which biological modelling would be a particular case of. Without reactions, we pretty much have that core language. My inclination is that biological

[cellml-discussion] CellML 1.1.1 specification

2007-07-18 Thread Andrew Miller
David Nickerson wrote: Andrew Miller wrote: David Nickerson wrote: From what I gather, publicity. We need some way to direct people's attention to our intention to deprecate reaction elements. sure - but its still not clear to me if 1.1.1 is making clear our

Re: [cellml-discussion] CellML 1.1.1 specification

2007-07-18 Thread David Nickerson
Correct me if I am wrong, but I believe that nothing in the text of the CellML 1.1 specification says that reactions will or will not be deprecated in any future version of CellML, and therefore there is no need for an erratum to CellML 1.1 (and indeed, such an erratum would be

Re: [cellml-discussion] CellML 1.1.1 specification

2007-07-18 Thread Andrew Miller
David Nickerson wrote: Correct me if I am wrong, but I believe that nothing in the text of the CellML 1.1 specification says that reactions will or will not be deprecated in any future version of CellML, and therefore there is no need for an erratum to CellML 1.1 (and indeed, such an