> > 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