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 _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
