Meeting Minutes 19 September 2007

Present: Randall Britten, Sarala Dissanayake, Poul Nielsen, Andrew Miller, James Lawson Apologies: Catherine Lloyd, Tommy Yu, Peter Hunter

Review of last week's action items:

  • Action Item 2007-09-12-1: Randall has yet to schedule a meeting on upgrading the CCGS on the Plone site.

    • New Action Item 1: Randall will arrange a meeting with the concerned parties about the CCGS.

  • Action Item 2007-09-12-2: Andrew has sent an e-mail to the cellml-discussion mailing list proposing that we disallow references to the same component more than once.

  • Action Item 2007-09-12-3: Randall has not yet had a discussion with Gareth about the process of deploying changes onto the live site.

    • New Action Item 2: Randall will have this discussion with Gareth de Walters (the Institute webmaster).

  • Action Item 2007-09-12-4: Randall has not yet evaluated how much work it would take to review all the pages to identify stale pages.

    • New Action Item 3: Randall will look into how much work is required to review the rest of the site so it can be split up amongst the appropriate people.

  • Action Item 2007-09-12-5: Randall has put Andre's items from last week onto the agenda.

Discussion of agenda items:

  • Agenda Item 4, about writing up documentation on the role and scope of the Auckland CellML Meetings, came up and so was discussed first. This led to a discussion of where there might be failures where we don't ask the community for feedback. Randall thinks that we should make it clear in anything we write up that decisions are made as a service to the CellML community and not as an attempt to dominate or control the direction taken. Poul also noted that we make decisions which we think are non-controversial (although it was noted that they sometimes later turn out to be) and try to give input on controversial issues. Randall thinks that as part of our process we should always check there has been adequate community consultation before making decisions.

    • Action Item 4: James will create a tracker item assigned to him to create the summary.

    • Action Item 5: Randall will create a 'Community' product in the tracker to hold such tracker items.

  • Agenda Item 1: CellML 1.1.1 + CellML 1.2 specification proposal

    • There was an in-depth discussion about the process of how we will deal with reactions. This was deferred for the breakaway meeting, see the notes on this at the end.

  • Agenda Item 2: CellML model repository development status update + directions.

    • James noted that there has been a paper which could guide directions for model curation (published December 2006 in the Journal of Experimental Biology, by Nic Smith, Edmund Crampin, Steve Niederer, Jim Bassingwaithe and Dan Beard).

    • Randall noted that Matt has been working on separating the content & repository.

    • We are still also waiting for Matt's requirements specification, and need to follow up on this with him.

    • Action Item 6: Poul will e-mail Matt for a status update.

  • Agenda Item 3: On plans for improving external involvement in CellML

    • James is going the BMES2007 conference in Los Angeles to promote CellML and has also created a poster entitled "CellML:, Tools & Community," for the upcoming ICSB2007 conference (he is not attending ICSB2007 - Edmund Crampin will be presenting the poster.)

    • Action Item 7: James will add a tracker item with a high priority reminding him to make a proposal on ways to improve external involvement.

  • Agenda Item 4: Already discussed, see above.

  • Agenda Item 5: Andre has asked about the use of voting in association with Bugzilla issues.

    • In terms of voting on issues to decide outcomes, Poul thinks that while the community is small, we can rely on establishing consensus via e-mail. James noted that a series of paragraphs with reasons for and against a proposal is much better than a simple set of numbers.

    • Andrew noted that votes in Bugzilla are not intended to decide the outcome of community decisions, but instead are a way to let members of the community to signal to people working on issues that this is important to them, and so people looking for issues to work on can identify issues that a lot of people care about.

  • Agenda Item 6: There has been a misunderstanding with Matt over the conditions of the tracker hosting, and we have been told that at some point in the future we will get 24 hours notice that the tracker will go down for some period of about a day and may require a restore from backup after that. Randall thinks that it is not worth taking time to restore the tracker onto that site if there is a risk we could need to do extra work because of this in the future. It could be weeks until IT get the final tracker deployed, so in the interim period we need a tracker. The decision was for now to keep using Andrew's workstation to host the tracker and require that everyone external tunnel in.

  • Agenda Item 7: The possibility of standardising our floating point representation used e.g. for initial_value attributes to use a decimal point as the decimal separator, as opposed to letting it vary with the country the CellML processing tools are in, was discussed. The consensus was that we should standardise the format in a similar way to what MathML does.

    • Action Item 8: Andrew will send a final e-mail to the list to see if there is any disagreement with this.

Breakaway session on versioning strategy for CellML

  • Present: Poul Nielsen, Randall Britten, Andrew Miller

  • Between CellML 1.0 and CellML 1.1, the namespace of all elements was changed.

  • This means that we have defined all elements again separately, rather than preserving some elements from previous versions.

  • At present, no CellML 1.0 models are valid CellML 1.1 models, and vice versa, even if the CellML 1.1 model doesn't use any features which are new in CellML 1.1.

  • Andrew feels that if we do it this way, there is no need for a deprecation mechanism because it is useless anyway, as changing the namespace will break all existing CellML tools.

  • Andrew was opposed to the idea of changing all the namespaces (Randall agreed with Andrew), and suggested changing the namespace of a particular element in only some circumstances:

    • When we add a new element that wasn't present in a previous version.

    • When we change the semantics of an element from the semantics in a previous version (but not including cases where what we wrote is different from what we intended, and everyone has implemented our intentions rather than the letter). In this case, both the old and new namespace would be valid and have the old and new semantics, but the element in the old namespace would be deprecated.

    • In other circumstances, we retain the same namespace on elements. This means that a valid CellML 1.2 model might be a mixture of elements in the CellML 1.1 and CellML 1.2 namespaces.

    • Newer versions of CellML would then try to include at least most of the models from previous versions of CellML (perhaps all models which don't use any features which were deprecated in the previous version). Deprecation now makes sense because we don't have completely incompatible specifications anyway.

  • Randall noted that this is what HTML, MathML, and many other specifications out there use. Poul also raised FORTRAN77 as an example. Andrew noted that if you don't use any features deprecated / removed / added the same program can be valid in several versions of FORTRAN.

  • Poul thinks that mixing namespaces means you have to scan the entire document before you can determine that you don't support a particular version of the model. Andrew doesn't see a problem with that. Randall suggested using a DTD, but Andrew thinks that we don't want to use that to check what version, because you actually want 1.2 models that don't use 1.2 features to work unchanged in CellML 1.1 tools. Randall agrees with this goal.

  • The problem of extension elements in CellML interacting badly with mixing namespaces was raised. At present, if you have a CellML 1.2 namespace element in a CellML 1.1 model, the CellML 1.1 specification says that any namespace except from a prescribed set (including future version namespaces) are extension namespaces, and elements in them are extension elements which get ignored. However, if there are features in a model defined in CellML version n and you load that in a version n-1 tool, ideally we want the tool to say that it doesn't support that version of CellML. This will require that elements in unknown namespaces starting with be treated not as extension elements but as an error. It is too late to fix this for CellML 1.1 but we can start doing this from CellML 1.2

  • There was some discussion clarifying what deprecation of an element from the specification means in practical terms.

  • There was a discussion of whether eventually breaking backwards compatibility is any worse than immediately breaking it. Andrew thinks that if we define our specifications so everyone only implements one version which includes previous versions, then it is better to make one version backwards compatible with the non-deprecated part, to allow for a period when some people are using old tools and some people are moving to new tools, rather than creating instant incompatibility between the tools.

  • There was some discussion about what namespace the model element should be in CellML 1.2. Randall suggested it should be in CellML 1.1 and not CellML 1.0 because we have already changed the namespaces for CellML 1.1 rather than mixing namespaces, and so that should be our baseline for future versions. Andrew agrees, noting that CellML 1.0 and CellML 1.1 are inherently incompatible, and we can't make CellML 1.2 models which don't use any new features simultaneously also valid CellML 1.1 and 1.0 models, we can only make it valid 1.2 + 1.1 or valid 1.2 + 1.0.

  • Poul is still not convinced on what approach is best, but due to insufficient time and the need to get community input the meeting was deferred until 3:00 pm on October 3, subject to confirmation that time slot is free for everyone involved. Andrew will draw this discussion to the attention of the community via the mailing list.