[cellml-discussion] CellML 1.1.1 specification

[Andrew Miller]

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