First login?
Lost password?
 
 
cellml-discussion AT lists.cellml.org 
CellML Discussion List

Text archives Help


[cellml-discussion] [Tracker Item 42] New: CellML 1.1.1specification


Chronological Thread 
  • From: ak.miller at auckland.ac.nz (Andrew Miller)
  • Subject: [cellml-discussion] [Tracker Item 42] New: CellML 1.1.1specification
  • Date: Wed, 18 Jul 2007 15:28:05 +1200
David Nickerson wrote:
> Hi Andrew,
>
> To simply delete reaction elements from a version 1.1.1 specification
> seems the wrong approach to me. This means that while a 1.0 model is a
> valid 1.1 model it could be an invalid 1.1.1 model. So the most minor
> version change is the one that invalidates the model?!?
>

CellML 1.0 models are not valid 1.1 models because they are in the
CellML 1.1 namespace.

I think that 1.1.1 is backwards compatible with 1.1 (all 1.1.1 models
are valid 1.1 models), it is simply a lack of forwards compatibility.
Compare this with the relationship between CellML 1.0 and CellML 1.1
(there is neither backwards nor forwards compatibility due to the
namespaces, and if you change the namespaces, there is forwards but not
backwards compatibility).

> If anything, a version 1.1.1 could mark the reaction element as
> deprecated but still valid. Although if I recall some other
> specification developments correctly (i.e., docbook), an element needs
> to be marked for deprecation a version before it is actually deprecated
> and removed from the language.

I think that reaction has been informally deprecated for quite some
time, and there has been an effort to get rid of most reactions.

> Not sure what process we want to follow
> for CellML but this 1.1.1 draft specification would not be the way I
> hope we go. Otherwise how can anyone have confidence in using CellML at
> all when core elements can arbitrarily be dropped from the specification
> with no notice?
>

We do need to change the CellML specification if we are to make
progress, and I think removing historical mistakes is as important as
adding new features. Models which are CellML 1.1 compliant will forever
remain CellML 1.1 compliant, because we are not changing CellML 1.1, and
instead we are making a new version of the specification. Everyone
expects that new versions of specifications will change some things.

Furthermore, I don't exactly agree that we need to give 'notice' of
things by way of formal specifications. Submitting a proposal for the
CellML community to review is sufficient 'notice'.

In the case of mature standards which require a high level of
interoperability, a +-1 compatibility strategy is a good idea. A good
example is the Subversion protocol
(http://subversion.tigris.org/faq.html#interop): "The client and server
are designed to work as long as they aren't more than one major release
version apart. For example, any 1.X client will work with a 1.Y server.
However, if the client and server versions don't match, certain features
may not be available". Under such a strategy, you generally use a 'be
liberal in what you accept, and conservative in what you send' strategy,
which in CellML terms would require tools to support reactions, but
require that no new models be developed that use reactions.

However, I don't think that this is a good approach for CellML:
1) CellML tools generally support more than one version of CellML
anyway. For example, the CellML API has been quite explicitly coded to
support both CellML 1.1 and CellML 1.0. I expect that tools would
continue to support 1.1, 1.1.1, and 1.0 (in fact, any tool which
supports 1.1 properly will immediately be able to claim support for
CellML 1.1.1 models without making any code changes).
2) As far as I know, no one has actually implemented a reaction based
simulator at the moment anyway.

I think that having a separate implementation notes document to describe
what I have summarised would probably be a better way to achieve this.

> Also, I'm wondering if we could set some ground rules for the
> development of new versions of CellML. Rather than people simply
> submitting draft specifications, I would favour an approach whereby
> people submit proposals (using whatever technology we end up using) and
> then we can discuss which version of CellML that proposal should be
> considered for.

Some one does also need to put these together to come up with a proposal
for a particular version (indeed, the document I produced does mop up a
list of issues on various pages and trackers and consolidate them into
one document).

I think that the process is:
1. Someone proposes issues for upcoming releases.
2. The group decides if they like the idea or not. If not, the idea
either gets dropped or the proposer goes off and creates their own
'fork' of CellML and calls it something new (or ideally, some compromise
is reached which achieves the same thing in a way everyone agrees on).
3. Someone collects proposals which are ready for inclusion into
CellML, and makes a proposed new version of CellML.
4. The group discusses the new version of CellML, and if they like it,
it becomes an official draft (which implementors are encouraged to work on).
5. Any problems in the official draft get fed back into it after going
through the community.
6. If model authors have found the draft useful, it gets frozen and
becomes final.

> This would allow us to start developing a detailed road
> map of the features people want to include in new versions of CellML and
> the priority with which they are incorporated, as well as possible
> target dates for the various releases.
>
This can be done quite easily with the Bugzilla based tracker, although
we don't have much data to base this off at the moment.

Best regards,
Andrew



Archive powered by MHonArc 2.6.18.

Top of page