Dear all I think that we are in agreement about the need to signal to the CellML community that the reaction element is deprecated. As I mentioned at the CellML meeting, I favour doing this by formally indicating so in the specification. I appreciate that some would like to move quickly on this issue by releasing a new version of CellML that has all references to the reaction element removed. I also agree with Andre that we need to be careful about suddenly removing a feature without having at least one specification release indicating our intention to do so. I would like to suggest that we try to resolve this issue by releasing a CellML 1.1a specification identical to the CellML 1.1 specification except that the 1.1a specification is annotated with a clear statement that the reaction element is deprecated and can be expected to be removed in future versions. Both specifications will operate under the same 1.1 namespace because they are functionally identical. It seems to me that this approach will satisfy both ends of the spectrum - CellML users are given a clear notice of our intentions while, for the interim, the specification remains unchanged.
Best wishes Poul On 2007 Jul 19, at 16:19, David Nickerson wrote: >> 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. > > All I'm trying to point out is that in the vast majority of XML/SGML > based standards in use today, including ones from the W3C as well as > SBML, elements are marked as deprecated before they are made obsolete > and removed from the specification. I don't see how this can be > seen to > be acting as a tutorial or newsletter? > >> 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). > > yes - such as indicating that a particular element is known to have > been > superseded by some new and better feature and that the element will be > phased out in some future version of the specification. > >> 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. > > While I agree that the reaction element should be removed and I am > certainly not trying to say that it should never be removed, I am just > saying that the way you are proposing to do this is not setting the > right kind of precedence for the way we want to evolve CellML. > > I also think you will find strong disagreement from the SBML community > on how reactions are poorly implemented reactions. > > > > Andre. > _______________________________________________ > cellml-discussion mailing list > [email protected] > http://www.cellml.org/mailman/listinfo/cellml-discussion _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
