CellML Discussion List

Text archives Help


[cellml-discussion] CellML 1.1.1 specification


Chronological Thread 
  • From: alan.garny at dpag.ox.ac.uk (Alan Garny)
  • Subject: [cellml-discussion] CellML 1.1.1 specification
  • Date: Thu, 19 Jul 2007 09:52:55 +0100

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





Archive powered by MHonArc 2.6.18.

Top of page