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? >
I think it partly depends on whether a specification aims to include all prior versions of the specification or not. Historically, support for a version of CellML has not included support for the previous version of CellML. Under such a regime, there is an implicit requirement to support multiple versions of CellML anyway, which makes the need to go through a deprecation phase unnecessary (compare with, for example, the HTML specification. Implementation of HTML4 will automatically cause a user agent to support all previous versions of HTML, hence the need for deprecation). > >> 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. > It would be useful to draw attention to the changes regarding the reaction element, although we probably don't want to put any normative text about what to replace it with in the specification, because that would be harmful to the separation of metadata from the core 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. > There are two ways of developing specifications while still remaining some interoperability between tools built at different times: 1) Define new versions which don't aim to be compatible with earlier versions, but state that tool implementors should implement the older version as well as the new version. 2) Build some compatibility mechanisms into the specification, such that by implementing a given version of the specification you are also implicitly creating compatibility with older versions. The existing precedent for CellML is strategy 1 above (e.g. CellML 1.1 used a completely different namespace to CellML 1.0, and CellML 1.1 doesn't say that tools should accept documents in the CellML 1.0 namespace). I believe that the way 1.1.1 is defined is compatible with the historical precedent to use strategy 1. I feel that what you are asking for is something that makes sense under strategy 2. If we want to adopt 'strategy 2' for CellML, then I have no objection, but we should make it absolutely explicit that we are doing this, that it is a change from how we have operated in the past, and ensure that everyone understands that is what we are discussing. A consequence of this would probably be that CellML 1.2 needs to define what CellML 1.2 compliant tools should accept from the CellML 1.0 and CellML 1.1 namespaces. Best regards, Andrew _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
