> 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
