Hi Andre, I'm not pretending to understand the CellML version numbering system, but to serve as an example, would you be suggesting that changes such as removing a reaction element are a proposal for a future say 1.2 versions where the namespace is changed?
Also, if there is something we call the proposal to remove reaction elements, I think there needs to be a way to present what the formal normative specification would look like if that were the case: which is the current 1.1 minus the reaction element and the associated DTD and Schema that represent these. The reason for this is that is we want to write a test implementation of this proposal, we want to be sure that by only using what information there is in that proposal that we indeed have enough to implement what we intended. I just don't know what to call this - is it 1.2a1, is it 1.1.1, is it 1.1-branch-reactions-removed? I think we agree that a proposal to remove reactions in warranted, I think we need to figure out how we publish the draft specification that would represent this. I think depreciation warnings are important, but don't form the core of the actual proposal - they sit at some level that goes with whatever it is that governs new version numbers and the notices we provide with those. cheers Matt On 7/19/07, David Nickerson <[EMAIL PROTECTED]> 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
