[cellml-discussion] CellML 1.1.1 specification

[David Nickerson]

Hi Poul,

That makes sense to me - although I would call it 1.1.1 rather than 1.1a 
which to me implies an alpha pre-release of 1.1.


Andre.

Poul Nielsen wrote:
> 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
> 
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

-- 
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: david.nickerson at nus.edu.sg