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 16:41:40 +1200
David Nickerson wrote:
>>> 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?
>

They don't need to determine whether they are looking at a 1.1.1 or 1.1
model. The changes are all corrections of minor errors which everyone
has just ignored and implemented how we intended it to be read, or
describe changes that an author will need to make as opposed to changes
that tool developers will need to make.

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

See above for why we don't have 1.0 to 1.1, so we can't expect 1.0 to
1.1.1. Do you mean 1.1 to 1.1.1?

>
>>> 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.
>
Most tool developers don't need to make any changes to support CellML
1.1.1 models, because CellML 1.1.1 is a subset of CellML 1.1, and so if
they support CellML 1.1.1 they also support CellML 1.1 (authors, on the
other hand, might be annoyed if they have just written a model in CellML
1.1, but such is the nature of an evolving specification).

Validators are the one exception, because in a particular mode they
might want to accept precisely CellML 1.1.1 and not models which are
valid CellML 1.1 but not valid CellML 1.1.1. However, changes like this
are to be expected for validators (and deprecation would be no more
onerous on such validators anyway).

I do not agree that specifications should act like some kind of 'news
bulletin' that describes not only the current specification, but also
things that are going to happen in the future. Developers can implement
an individual specification perfectly well based solely on that
specification, and if they want to know what is going to happen soon,
then it is certainly more appropriate for them to look at mailing lists
and trackers than to look at the last version 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.
Such is the nature of how specifications develop.
> 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?
>
I don't think that this is the point, given that we are having this
whole discussion based on establishing principles which will increase
developer confidence to implement CellML.
>
>> 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.
>
BioPAX annotations will probably be the way to go for this (I believe
James is looking into this).
>
>> 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.

Who actually does the work is really a funding driven thing rather than
a community thing (as a community, we can't tell someone to work on a
particular task, we can only suggest which tasks are needed). A large
number of open source projects adopt exactly the same solution: make a
list of what needs to be done, let each individual (or whoever is
funding them) decide on what actually gets done from this list, and work
from there. Requiring community review and approval of the work that is
actually done, as opposed to community decisions on what work should be
done ensures that everyone knows exactly what they are agreeing to, and
also creates a fairly centralised 'trunk' of what actually gets written,
off which future changes can be based.

> 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.
>
I think the Bugzilla-based tracker will give us this for free as long as
we a vigilant in putting these issues into the tracker with sufficient
amounts of meta-data about them.

Best regards,
Andrew

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



Archive powered by MHonArc 2.6.18.

Top of page