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: matt.halstead at auckland.ac.nz (Matt )
  • Subject: [cellml-discussion] [Tracker Item 42] New: CellML 1.1.1specification
  • Date: Wed, 18 Jul 2007 16:28:50 +1200
>
> 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.
>


I think Andre was pointing more at a more formal process that anyone
could participate in and that more than one initial proposal for "new
versions" of things, such as specifications, could be created in a
setting where they can be referenced as a group.

The technology we are looking at (albeit slowly) is the plone software
center, and specifically relevant here are the proposal utility - e.g.
see: http://plone.org/products/plone/roadmap - specifically -
http://plone.org/products/plone/roadmap#discussion


Archive powered by MHonArc 2.6.18.

Top of page