[cellml-discussion] CellML 1.1.1 specification

[Poul Nielsen]

Dear all

I think that we are in agreement about the need to signal to the  
CellML community that the reaction element is deprecated. As I  
mentioned at the CellML meeting, I favour doing this by formally  
indicating so in the specification. I appreciate that some would like  
to move quickly on this issue by releasing a new version of CellML  
that has all references to the reaction element removed. I also agree  
with Andre that we need to be careful about suddenly removing a  
feature without having at least one specification release indicating  
our intention to do so. I would like to suggest that we try to  
resolve this issue by releasing a CellML 1.1a specification identical  
to the CellML 1.1 specification except that the 1.1a specification is  
annotated with a clear statement that the reaction element is  
deprecated and can be expected to be removed in future versions. Both  
specifications will operate under the same 1.1 namespace because they  
are functionally identical. It seems to me that this approach will  
satisfy both ends of the spectrum - CellML users are given a clear  
notice of our intentions while, for the interim, the specification  
remains unchanged.

Best wishes
Poul

On 2007 Jul 19, at 16:19, 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?
>
>> 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
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion