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 [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
