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: david.nickerson at nus.edu.sg (David Nickerson)
  • Subject: [cellml-discussion] [Tracker Item 42] New:CellML 1.1.1specification
  • Date: Wed, 18 Jul 2007 12:10:11 +0800
>> 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.

but given you are proposing not to change the namespace, how do
applications determine if they are looking at a CellML 1.1 or a 1.1.1
version model?

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

yes, and its this forward compatibility I am concerned with - at least
as far as CellML 1.0 to CellML 1.1.x compatibility is concerned.

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

thats the main problem I have - we had an option to formally mark the
reaction element for deprecation in 1.1 and the decision was made to not
do so. I have heard no reason why that decision no longer holds? While
attempting to develop community standards I don't think it is
appropriate to base specification revisions at such an informal level.
Application developers should be able to implement support for CellML
based on the specifications alone, not some combination of
specifications and trawling through mailing lists and bug trackers. As
an application developer I would be extremely annoyed to spend time
implementing support for an apparent core element just to have it
arbitrarily removed in a minor increment of the specification.

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

Change is fine, its the abrupt deletion of an until now core element in
CellML that I have concerns with. And classifying the reaction element
as a historical mistake seems a bit harsh given the CellML project would
probably not exist today if not for reaction elements.

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

see my concerns above.

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

name one tool outside the institute and my tools that supports CellML
1.1 models?

> 2) As far as I know, no one has actually implemented a reaction based
> simulator at the moment anyway.

simulator - no, but I think you want to look at the extensive use of
reaction elements in the SBML translation tools and the use people put
those to.

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

yes, I'd just like to see this process a bit more formalised rather than
someone picking and choosing issues raised on the mailing list or other
discussion forums. I would also like to be able to see how things are
evolving in terms of issues proposed but put off for future versions -
variable typing is one example.

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

sure - once (and if) the bugzilla tracker is available to the community
I would assume that hows this process would be done.


Andre.


Archive powered by MHonArc 2.6.18.

Top of page