Re: [cellml-discussion] CellML 1.1.1 specification

[Matt]

More generally I think this issue is tapping on the bigger issue of a
core modelling language and specification, and then special use cases,
of which biological modelling would be a particular case of.

Without reactions, we pretty much have that core language.

My inclination is that biological modelling is a specification of
minimum required annotation of mathematical models using the 'core'
language.

Poul's turn.


On 7/20/07, James Lawson <[EMAIL PROTECTED]> wrote:
> David Nickerson wrote:
> > Matt wrote:
> >>> It seems there is some misunderstanding as to whether we are discussing
> >>> a proposal to remove the reaction element from CellML or a proposed new
> >>> specification. I thought it was the latter but you seem to be talking
> >>> about the former...
> >>
> >> Both. I think.
> >>
> >> So I will try another explanation.
> >>
> >> If we had our specification in a version control system and tagged out
> >> releases and release candidates etc, and if we followed a protocol of
> >> releasing at least one stable minor release that marks depreciation
> >> only, then the following would be the result (in my mind)
> >>
> >> - The current trunk is the development version of cellml 1.2 (i.e.
> >> unreleased-dev).
> >> - This current trunk look likes CellML 1.1 and the associated
> >> definitions in DTDs etc.
> >> - We update this to mark out that reaction elements are going to be
> >> depreciated, this includes comments in DTDs etc. We don't remove
> >> reaction elements from the specification at this stage because that's
> >> where we hang the depreciation notices.
> >> - We tag this as 1.1.1 and release it
> >> - We then delete reaction elements from the specification that is on trunk.
> >>
> >> Now, this is the kind of process I think covers the steps you have
> >> been talking about and at the end makes available a trunk version of
> >> 1.2-dev-unreleased that doesn't have reaction elements that people can
> >> check out an play with (this is essentially the proposal page the
> >> Andrew wrote up - though I think there are issues remaining now with
> >> the absence of biology from a "Cell" ML standard.
> >
> > yep - thats how I would see the specification evolving over time,
> > subject, of course, to the various proposals being accepted and assigned
> > to an appropriate version.
> >
> > I think the absence of biology from the core specification is probably a
> > good thing,
>
> It might be worth adding an editorial comment or similar to note that
> the metadata is where the vast majority of biological information is
> defined.
>
> but there needs to be clear annotation of the specification
> > describing how reactions should now be represented in a world without
> > reactions - another best practice recommendation and examples in the
> > model repository at the least, I would hope.
>
> Yep, the 'signal transduction' tutorial will no longer be needed, since
> its main purpose is to describe the best practice for use of reaction
> elements to describe biochemical pathways. The question will be, do we
> just remove it, or do we create a new tutorial that is biochem specific,
> but doesn't talk about reaction elements. For example, there are two
> main ways to code up a biochem model: either you can use equations that
> describe, for example, the rate of change of conc. of species A, where
> species A might have a few different processes acting on it, so this
> equation would be a summation of the effect of these processes, OR, you
> can split the equation into 'fluxes,' which represent just the effect of
> one process on a species at a time. I think it would be worth writing a
> best practice guide for writing biochem models, even if it is relatively
> short, since there are a few things that are different from how an ephys
> model should be coded up.
>
> >
> >> But what I am also saying is that this is still just an idea, so it
> >> should be put forward as a proposal that has not been accepted. I.e.
> >> that the steps I described above are purely hypothetical at the
> >> moment, since we haven't had the chance to hear arguments from people
> >> about it - it might turn out to be a silly proposal.
> >
> > definitely. Your steps describe the process for how the specification
> > may be updated, developed, etc., but each release will be the result of
> > a set of proposals being accepted and assigned to that particular release.
> >
> > this is why the proposal to remove the reaction element should have
> > first been put forward independently of any specific future version of
> > CellML.
>
> Perhaps we could start by formalising the actual proposal to get rid of
> the rxn element. Why are we doing it? How will we replace the purpose it
> served, using metadata for example? I realise that this has been
> discussed a lot in an informal manner, and was in fact decided well
> before my time, but I guess if we're going to do something as major as
> create a new spec version, we should build the foundations

Re: [cellml-discussion] CellML 1.1.1 specification

[James Lawson]

David Nickerson wrote:
> Matt wrote:
>>> It seems there is some misunderstanding as to whether we are discussing
>>> a proposal to remove the reaction element from CellML or a proposed new
>>> specification. I thought it was the latter but you seem to be talking
>>> about the former...
>>
>> Both. I think.
>>
>> So I will try another explanation.
>>
>> If we had our specification in a version control system and tagged out
>> releases and release candidates etc, and if we followed a protocol of
>> releasing at least one stable minor release that marks depreciation
>> only, then the following would be the result (in my mind)
>>
>> - The current trunk is the development version of cellml 1.2 (i.e.
>> unreleased-dev).
>> - This current trunk look likes CellML 1.1 and the associated
>> definitions in DTDs etc.
>> - We update this to mark out that reaction elements are going to be
>> depreciated, this includes comments in DTDs etc. We don't remove
>> reaction elements from the specification at this stage because that's
>> where we hang the depreciation notices.
>> - We tag this as 1.1.1 and release it
>> - We then delete reaction elements from the specification that is on trunk.
>>
>> Now, this is the kind of process I think covers the steps you have
>> been talking about and at the end makes available a trunk version of
>> 1.2-dev-unreleased that doesn't have reaction elements that people can
>> check out an play with (this is essentially the proposal page the
>> Andrew wrote up - though I think there are issues remaining now with
>> the absence of biology from a "Cell" ML standard.
> 
> yep - thats how I would see the specification evolving over time, 
> subject, of course, to the various proposals being accepted and assigned 
> to an appropriate version.
> 
> I think the absence of biology from the core specification is probably a 
> good thing, 

It might be worth adding an editorial comment or similar to note that
the metadata is where the vast majority of biological information is
defined.

but there needs to be clear annotation of the specification
> describing how reactions should now be represented in a world without 
> reactions - another best practice recommendation and examples in the 
> model repository at the least, I would hope.

Yep, the 'signal transduction' tutorial will no longer be needed, since
its main purpose is to describe the best practice for use of reaction
elements to describe biochemical pathways. The question will be, do we
just remove it, or do we create a new tutorial that is biochem specific,
but doesn't talk about reaction elements. For example, there are two
main ways to code up a biochem model: either you can use equations that
describe, for example, the rate of change of conc. of species A, where
species A might have a few different processes acting on it, so this
equation would be a summation of the effect of these processes, OR, you
can split the equation into 'fluxes,' which represent just the effect of
one process on a species at a time. I think it would be worth writing a
best practice guide for writing biochem models, even if it is relatively
short, since there are a few things that are different from how an ephys
model should be coded up.

> 
>> But what I am also saying is that this is still just an idea, so it
>> should be put forward as a proposal that has not been accepted. I.e.
>> that the steps I described above are purely hypothetical at the
>> moment, since we haven't had the chance to hear arguments from people
>> about it - it might turn out to be a silly proposal.
> 
> definitely. Your steps describe the process for how the specification 
> may be updated, developed, etc., but each release will be the result of 
> a set of proposals being accepted and assigned to that particular release.
> 
> this is why the proposal to remove the reaction element should have 
> first been put forward independently of any specific future version of 
> CellML. 

Perhaps we could start by formalising the actual proposal to get rid of
the rxn element. Why are we doing it? How will we replace the purpose it
served, using metadata for example? I realise that this has been
discussed a lot in an informal manner, and was in fact decided well
before my time, but I guess if we're going to do something as major as
create a new spec version, we should build the foundations first.

In this discussion forum we could then debate the merits of this
> proposal and, if deemed suitable, develop a schedule for the 
> implementation of the proposal (i.e., mark reaction element for 
> deprecation in 1.1.1 and then remove the reaction element in 1.2). Other 
> proposals would also be similarly evaluated and possibly assigned to the 
> same or different releases of the CellML specification.
> 
> It definitely should not, at this stage, be a forgone conclusion that 
> the reaction element should be removed in 1.2 (or some specific future 
> version of CellML) - that is still open to discussion in my

Re: [cellml-discussion] CellML 1.1.1 specification

[Alan Garny]

> > If we had our specification in a version control system and tagged
> out
> > releases and release candidates etc, and if we followed a protocol of
> > releasing at least one stable minor release that marks depreciation
> > only, then the following would be the result (in my mind)
> >
> > - The current trunk is the development version of cellml 1.2 (i.e.
> > unreleased-dev).
> > - This current trunk look likes CellML 1.1 and the associated
> > definitions in DTDs etc.
> > - We update this to mark out that reaction elements are going to be
> > depreciated, this includes comments in DTDs etc. We don't remove
> > reaction elements from the specification at this stage because that's
> > where we hang the depreciation notices.
> > - We tag this as 1.1.1 and release it
> > - We then delete reaction elements from the specification that is on
> trunk.
> >
> > Now, this is the kind of process I think covers the steps you have
> > been talking about and at the end makes available a trunk version of
> > 1.2-dev-unreleased that doesn't have reaction elements that people
> can
> > check out an play with (this is essentially the proposal page the
> > Andrew wrote up - though I think there are issues remaining now with
> > the absence of biology from a "Cell" ML standard.
> 
> yep - thats how I would see the specification evolving over time,
> subject, of course, to the various proposals being accepted and
> assigned
> to an appropriate version.
> 
> I think the absence of biology from the core specification is probably
> a
> good thing, but there needs to be clear annotation of the specification
> describing how reactions should now be represented in a world without
> reactions - another best practice recommendation and examples in the
> model repository at the least, I would hope.
> 
> > But what I am also saying is that this is still just an idea, so it
> > should be put forward as a proposal that has not been accepted. I.e.
> > that the steps I described above are purely hypothetical at the
> > moment, since we haven't had the chance to hear arguments from people
> > about it - it might turn out to be a silly proposal.
> 
> definitely. Your steps describe the process for how the specification
> may be updated, developed, etc., but each release will be the result of
> a set of proposals being accepted and assigned to that particular
> release.
> 
> this is why the proposal to remove the reaction element should have
> first been put forward independently of any specific future version of
> CellML. In this discussion forum we could then debate the merits of
> this
> proposal and, if deemed suitable, develop a schedule for the
> implementation of the proposal (i.e., mark reaction element for
> deprecation in 1.1.1 and then remove the reaction element in 1.2).
> Other
> proposals would also be similarly evaluated and possibly assigned to
> the
> same or different releases of the CellML specification.
> 
> It definitely should not, at this stage, be a forgone conclusion that
> the reaction element should be removed in 1.2 (or some specific future
> version of CellML) - that is still open to discussion in my mind,
> especially in regard to the tools that biomodels.net are using to
> import/export CellML models with their repository and any other tools
> utilising the reaction element, of which I don't think anyone has yet
> evaluated.

This is also how I see it: CellML 1.1.1 marking reaction element for
deprecation and then CellML 1.2 removing it.

Alan.

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] CellML 1.1.1 specification

[David Nickerson]

Matt wrote:
>> It seems there is some misunderstanding as to whether we are discussing
>> a proposal to remove the reaction element from CellML or a proposed new
>> specification. I thought it was the latter but you seem to be talking
>> about the former...
> 
> 
> Both. I think.
> 
> So I will try another explanation.
> 
> If we had our specification in a version control system and tagged out
> releases and release candidates etc, and if we followed a protocol of
> releasing at least one stable minor release that marks depreciation
> only, then the following would be the result (in my mind)
> 
> - The current trunk is the development version of cellml 1.2 (i.e.
> unreleased-dev).
> - This current trunk look likes CellML 1.1 and the associated
> definitions in DTDs etc.
> - We update this to mark out that reaction elements are going to be
> depreciated, this includes comments in DTDs etc. We don't remove
> reaction elements from the specification at this stage because that's
> where we hang the depreciation notices.
> - We tag this as 1.1.1 and release it
> - We then delete reaction elements from the specification that is on trunk.
> 
> Now, this is the kind of process I think covers the steps you have
> been talking about and at the end makes available a trunk version of
> 1.2-dev-unreleased that doesn't have reaction elements that people can
> check out an play with (this is essentially the proposal page the
> Andrew wrote up - though I think there are issues remaining now with
> the absence of biology from a "Cell" ML standard.

yep - thats how I would see the specification evolving over time, 
subject, of course, to the various proposals being accepted and assigned 
to an appropriate version.

I think the absence of biology from the core specification is probably a 
good thing, but there needs to be clear annotation of the specification 
describing how reactions should now be represented in a world without 
reactions - another best practice recommendation and examples in the 
model repository at the least, I would hope.

> But what I am also saying is that this is still just an idea, so it
> should be put forward as a proposal that has not been accepted. I.e.
> that the steps I described above are purely hypothetical at the
> moment, since we haven't had the chance to hear arguments from people
> about it - it might turn out to be a silly proposal.

definitely. Your steps describe the process for how the specification 
may be updated, developed, etc., but each release will be the result of 
a set of proposals being accepted and assigned to that particular release.

this is why the proposal to remove the reaction element should have 
first been put forward independently of any specific future version of 
CellML. In this discussion forum we could then debate the merits of this 
proposal and, if deemed suitable, develop a schedule for the 
implementation of the proposal (i.e., mark reaction element for 
deprecation in 1.1.1 and then remove the reaction element in 1.2). Other 
proposals would also be similarly evaluated and possibly assigned to the 
same or different releases of the CellML specification.

It definitely should not, at this stage, be a forgone conclusion that 
the reaction element should be removed in 1.2 (or some specific future 
version of CellML) - that is still open to discussion in my mind, 
especially in regard to the tools that biomodels.net are using to 
import/export CellML models with their repository and any other tools 
utilising the reaction element, of which I don't think anyone has yet 
evaluated.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] CellML 1.1.1 specification

[Matt]

>
> It seems there is some misunderstanding as to whether we are discussing
> a proposal to remove the reaction element from CellML or a proposed new
> specification. I thought it was the latter but you seem to be talking
> about the former...


Both. I think.

So I will try another explanation.

If we had our specification in a version control system and tagged out
releases and release candidates etc, and if we followed a protocol of
releasing at least one stable minor release that marks depreciation
only, then the following would be the result (in my mind)

- The current trunk is the development version of cellml 1.2 (i.e.
unreleased-dev).
- This current trunk look likes CellML 1.1 and the associated
definitions in DTDs etc.
- We update this to mark out that reaction elements are going to be
depreciated, this includes comments in DTDs etc. We don't remove
reaction elements from the specification at this stage because that's
where we hang the depreciation notices.
- We tag this as 1.1.1 and release it
- We then delete reaction elements from the specification that is on trunk.

Now, this is the kind of process I think covers the steps you have
been talking about and at the end makes available a trunk version of
1.2-dev-unreleased that doesn't have reaction elements that people can
check out an play with (this is essentially the proposal page the
Andrew wrote up - though I think there are issues remaining now with
the absence of biology from a "Cell" ML standard.

But what I am also saying is that this is still just an idea, so it
should be put forward as a proposal that has not been accepted. I.e.
that the steps I described above are purely hypothetical at the
moment, since we haven't had the chance to hear arguments from people
about it - it might turn out to be a silly proposal.

cheers
Matt
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] CellML 1.1.1 specification

[David Nickerson]

> I'm not pretending to understand the CellML version numbering system,
> but to serve as an example, would you be suggesting that changes such
> as removing a reaction element are a proposal for a future say 1.2
> versions where the namespace is changed?

yes. assuming there is a 1.1.1 (or 1.1a) specification as outlined by Poul.

> Also, if there is something we call the proposal to remove reaction
> elements, I think there needs to be a way to present what the formal
> normative specification would look like if that were the case: which
> is the current 1.1 minus the reaction element and the associated DTD
> and Schema that represent these. The reason for this is that is we
> want to write a test implementation of this proposal, we want to be
> sure that by only using what information there is in that proposal
> that we indeed have enough to implement what we intended. I just don't
> know what to call this - is it 1.2a1, is it 1.1.1, is it
> 1.1-branch-reactions-removed?

wouldn't this simply be the implementation of the draft 1.2 
specification? The same as when we went from 1.0 to 1.1

> I think we agree that a proposal to remove reactions in warranted, I
> think we need to figure out how we publish the draft specification
> that would represent this.

a proposal to remove the reaction element is just one potential 
candidate for inclusion in the next revision of the CellML 
specification. Things like simple variable typing may also be worth 
considering in a 1.2 version.

> I think depreciation warnings are important, but don't form the core
> of the actual proposal - they sit at some level that goes with
> whatever it is that governs new version numbers and the notices we
> provide with those.

right - and the thing that governs this is the specification, isn't it? 
the deprecation notice is nothing to do with a proposal to remove the 
reaction element, it is one of the steps that must be gone through in 
order to achieve the desired goal of the proposal.

It seems there is some misunderstanding as to whether we are discussing 
a proposal to remove the reaction element from CellML or a proposed new 
specification. I thought it was the latter but you seem to be talking 
about the former...
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [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@cellml.org
>> http://www.cellml.org/mailman/listinfo/cellml-discussion
> 
> ___
> cellml-discussion mailing list
> cellml-discussion@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: [EMAIL PROTECTED]
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [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@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] CellML 1.1.1 specification

[Matt]

Hi Andre,

I'm not pretending to understand the CellML version numbering system,
but to serve as an example, would you be suggesting that changes such
as removing a reaction element are a proposal for a future say 1.2
versions where the namespace is changed?

Also, if there is something we call the proposal to remove reaction
elements, I think there needs to be a way to present what the formal
normative specification would look like if that were the case: which
is the current 1.1 minus the reaction element and the associated DTD
and Schema that represent these. The reason for this is that is we
want to write a test implementation of this proposal, we want to be
sure that by only using what information there is in that proposal
that we indeed have enough to implement what we intended. I just don't
know what to call this - is it 1.2a1, is it 1.1.1, is it
1.1-branch-reactions-removed?

I think we agree that a proposal to remove reactions in warranted, I
think we need to figure out how we publish the draft specification
that would represent this.

I think depreciation warnings are important, but don't form the core
of the actual proposal - they sit at some level that goes with
whatever it is that governs new version numbers and the notices we
provide with those.

cheers
Matt


On 7/19/07, David Nickerson <[EMAIL PROTECTED]> 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@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion
>
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [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.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [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  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 
"

   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

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] CellML 1.1.1 specification

[David Nickerson]

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


Andre.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion