[cellml-discussion] CellML 1.1.1 specification

[David Nickerson]

> 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.