Re: [cellml-discussion] CellML 1.1.1 specification
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 trunk is the development version of cellml 1.2 (i.e. unreleased-dev). - This current trunk look likes CellML 1.1 and the associated definitions in DTDs etc. - We update this to mark out that reaction elements are going to be depreciated, this includes comments in DTDs etc. We don't remove reaction elements from the specification at this stage because that's where we hang the depreciation notices. - We tag this as 1.1.1 and release it - We then delete reaction elements from the specification that is on trunk. Now, this is the kind of process I think covers the steps you have been talking about and at the end makes available a trunk version of 1.2-dev-unreleased that doesn't have reaction elements that people can check out an play with (this is essentially the proposal page the Andrew wrote up - though I think there are issues remaining now with the absence of biology from a Cell ML standard. yep - thats how I would see the specification evolving over time, subject, of course, to the various proposals being accepted and assigned to an appropriate version. I think the absence of biology from the core specification is probably a good thing, but there needs to be clear annotation of the specification describing how reactions should now be represented in a world without reactions - another best practice recommendation and examples in the model repository at the least, I would hope. But what I am also saying is that this is still just an idea, so it should be put forward as a proposal that has not been accepted. I.e. that the steps I described above are purely hypothetical at the moment, since we haven't had the chance to hear arguments from people about it - it might turn out to be a silly proposal. definitely. Your steps describe the process for how the specification may be updated, developed, etc., but each release will be the result of a set of proposals being accepted and assigned to that particular release. this is why the proposal to remove the reaction element should have first been put forward independently of any specific future version of CellML. In this discussion forum we could then debate the merits of this proposal and, if deemed suitable, develop a schedule for the implementation of the proposal (i.e., mark reaction element for deprecation in 1.1.1 and then remove the reaction element in 1.2). Other proposals would also be similarly evaluated and possibly assigned to the same or different releases of the CellML specification. It definitely should not, at this stage, be a forgone conclusion that the reaction element should be removed in 1.2 (or some specific future version of CellML) - that is still open to discussion in my mind, especially in regard to the tools that biomodels.net are using to import/export CellML models with their repository and any other tools utilising the reaction element, of which I don't think anyone has yet evaluated. This is also how I see it: CellML 1.1.1 marking reaction element for deprecation and then CellML 1.2 removing it. Alan. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] CellML 1.1.1 specification
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 will try another explanation. 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 trunk is the development version of cellml 1.2 (i.e. unreleased-dev). - This current trunk look likes CellML 1.1 and the associated definitions in DTDs etc. - We update this to mark out that reaction elements are going to be depreciated, this includes comments in DTDs etc. We don't remove reaction elements from the specification at this stage because that's where we hang the depreciation notices. - We tag this as 1.1.1 and release it - We then delete reaction elements from the specification that is on trunk. Now, this is the kind of process I think covers the steps you have been talking about and at the end makes available a trunk version of 1.2-dev-unreleased that doesn't have reaction elements that people can check out an play with (this is essentially the proposal page the Andrew wrote up - though I think there are issues remaining now with the absence of biology from a Cell ML standard. yep - thats how I would see the specification evolving over time, subject, of course, to the various proposals being accepted and assigned to an appropriate version. I think the absence of biology from the core specification is probably a good thing, It might be worth adding an editorial comment or similar to note that the metadata is where the vast majority of biological information is defined. but there needs to be clear annotation of the specification describing how reactions should now be represented in a world without reactions - another best practice recommendation and examples in the model repository at the least, I would hope. Yep, the 'signal transduction' tutorial will no longer be needed, since its main purpose is to describe the best practice for use of reaction elements to describe biochemical pathways. The question will be, do we just remove it, or do we create a new tutorial that is biochem specific, but doesn't talk about reaction elements. For example, there are two main ways to code up a biochem model: either you can use equations that describe, for example, the rate of change of conc. of species A, where species A might have a few different processes acting on it, so this equation would be a summation of the effect of these processes, OR, you can split the equation into 'fluxes,' which represent just the effect of one process on a species at a time. I think it would be worth writing a best practice guide for writing biochem models, even if it is relatively short, since there are a few things that are different from how an ephys model should be coded up. But what I am also saying is that this is still just an idea, so it should be put forward as a proposal that has not been accepted. I.e. that the steps I described above are purely hypothetical at the moment, since we haven't had the chance to hear arguments from people about it - it might turn out to be a silly proposal. definitely. Your steps describe the process for how the specification may be updated, developed, etc., but each release will be the result of a set of proposals being accepted and assigned to that particular release. this is why the proposal to remove the reaction element should have first been put forward independently of any specific future version of CellML. Perhaps we could start by formalising the actual proposal to get rid of the rxn element. Why are we doing it? How will we replace the purpose it served, using metadata for example? I realise that this has been discussed a lot in an informal manner, and was in fact decided well before my time, but I guess if we're going to do something as major as create a new spec version, we should build the foundations first. In this discussion forum we could then debate the merits of this proposal and, if deemed suitable, develop a schedule for the implementation of the proposal (i.e., mark reaction element for deprecation in 1.1.1 and then remove the reaction element in 1.2). Other proposals would also be similarly evaluated and possibly assigned to the same or different releases of the CellML specification. It definitely should not, at this stage, be a forgone conclusion that the reaction element should be removed in 1.2 (or some specific future version of CellML) - that is still open to discussion in my mind, It would be good to see a thorough list of pros and cons for the rxn element. If we do write a
Re: [cellml-discussion] CellML 1.1.1 specification
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 modelling is a specification of minimum required annotation of mathematical models using the 'core' language. Poul's turn. On 7/20/07, James Lawson [EMAIL PROTECTED] wrote: 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 will try another explanation. 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 trunk is the development version of cellml 1.2 (i.e. unreleased-dev). - This current trunk look likes CellML 1.1 and the associated definitions in DTDs etc. - We update this to mark out that reaction elements are going to be depreciated, this includes comments in DTDs etc. We don't remove reaction elements from the specification at this stage because that's where we hang the depreciation notices. - We tag this as 1.1.1 and release it - We then delete reaction elements from the specification that is on trunk. Now, this is the kind of process I think covers the steps you have been talking about and at the end makes available a trunk version of 1.2-dev-unreleased that doesn't have reaction elements that people can check out an play with (this is essentially the proposal page the Andrew wrote up - though I think there are issues remaining now with the absence of biology from a Cell ML standard. yep - thats how I would see the specification evolving over time, subject, of course, to the various proposals being accepted and assigned to an appropriate version. I think the absence of biology from the core specification is probably a good thing, It might be worth adding an editorial comment or similar to note that the metadata is where the vast majority of biological information is defined. but there needs to be clear annotation of the specification describing how reactions should now be represented in a world without reactions - another best practice recommendation and examples in the model repository at the least, I would hope. Yep, the 'signal transduction' tutorial will no longer be needed, since its main purpose is to describe the best practice for use of reaction elements to describe biochemical pathways. The question will be, do we just remove it, or do we create a new tutorial that is biochem specific, but doesn't talk about reaction elements. For example, there are two main ways to code up a biochem model: either you can use equations that describe, for example, the rate of change of conc. of species A, where species A might have a few different processes acting on it, so this equation would be a summation of the effect of these processes, OR, you can split the equation into 'fluxes,' which represent just the effect of one process on a species at a time. I think it would be worth writing a best practice guide for writing biochem models, even if it is relatively short, since there are a few things that are different from how an ephys model should be coded up. But what I am also saying is that this is still just an idea, so it should be put forward as a proposal that has not been accepted. I.e. that the steps I described above are purely hypothetical at the moment, since we haven't had the chance to hear arguments from people about it - it might turn out to be a silly proposal. definitely. Your steps describe the process for how the specification may be updated, developed, etc., but each release will be the result of a set of proposals being accepted and assigned to that particular release. this is why the proposal to remove the reaction element should have first been put forward independently of any specific future version of CellML. Perhaps we could start by formalising the actual proposal to get rid of the rxn element. Why are we doing it? How will we replace the purpose it served, using metadata for example? I realise that this has been discussed a lot in an informal manner, and was in fact decided well before my time, but I guess if we're going to do something as major as create a new spec version, we should build the foundations first. In this discussion forum we could then debate the merits of this proposal and, if deemed suitable, develop a schedule for the implementation of the proposal (i.e., mark
[cellml-discussion] CellML 1.1.1 specification
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 intention to deprecate reaction elements or if it is making reaction elements invalid in a 1.1.1 version model? I think that both are true: 1) Reaction elements would be invalid in the 1.1.1 specification I proposed. 2) Versions of CellML earlier than 1.1.1 would be deprecated by virtue of the fact that they are no longer the latest version of CellML, and therefore reaction elements are deprecated. but neither of these address our intention to deprecate the reaction element. I don't really understand what you are trying to say. How does releasing a new version which does not contain the reaction element not show an intention that the reaction element be deprecated)? I think that people who look at CellML at present are not sufficiently discouraged from using reaction elements, and I agree that a new version is reasonable to publicise what we as a community think is the proper direction for CellML. just to reiterate, when raising the issue of marking the reaction element for deprecation in the final 1.1 specification the decision was made to not do so and at the time it was also decided that the next version of cellml would be the one to formally mark the reaction element for deprecation. If this decision has been revisited and found in error, then the errata for the 1.1 specification should be updated to reflect that. Errata are primarily there to correct errors in the specification, not errors in the process by which the specification arose, or to make substantive changes to the specification. 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 inappropriate). Best regards, Andrew ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] CellML 1.1.1 specification
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 erratum would be inappropriate). exactly, and as a core element with an entire top level section of the 1.0 and 1.1 specifications devoted to it and with no annotation to state that it is not going to be around much longer it is reasonable to expect that the reaction element will remain in the next version of the specification. To have the reaction element go from a significant core element in 1.0 and 1.1 to obsolete in 1.1.1 with no formal deprecation step just seems wrong to me - maybe I'm the only one that sees any problems here? While the reaction element is obviously one that we want to get rid of, what kind of precedence are we setting for the evolution of CellML by simply deleting it with nothing more formal than saying its about time we tidied up that mess? Hi Andre, I think that we disagree about how the specification process should work and what it aims to address. I see a given version of a CellML specification as being a 'protocol' which both tools and model authors speak, therefore allowing them to interwork. In my view, it is inappropriate for specifications to act like either tutorials or newsletters (a small amount of such editorial material may be appropriate and useful in some cases, but it should not detract from the primary goal of the specification, which is to provide a normative definition of that particular version of CellML). Tools are encouraged to process multiple versions of CellML (section 4.1 of RFC4708 http://www.rfc-editor.org/rfc/rfc4708.txt says that As efforts are made to keep the number of specific formats small, user agents SHOULD implement all specific formats listed in the CellML Umbrella Format Registry at the time they were developed.). Therefore, tools will continue to support reaction elements for as long as they decide they want to support CellML 1.1 (and 1.0). I think that deleting things from newer specifications is common, and indeed, the IETF process, which has given rise to most good quality protocols in use on the Internet today, calls for unused features to be deleted prior to something becoming a draft standard: section 4.1.2 of RFC2026 http://www.rfc-editor.org/rfc/rfc2026.txt The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. If IETF believes that it is okay to remove features simply be removed because they have never been implemented, then certainly we should at least allow them to be removed if they are not only poorly implemented but also a bad fit conceptually. Best regards, Andrew ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
