[cellml-discussion] CellML version interoperability strategy

[Andrew Miller]

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