[cellml-discussion] Call for community input: final decisions on a number of specification related issues

[Andrew Miller]

Hi all,

There are a number of items in the CellML tracker regarding decisions 
about the next version of the CellML specification, which have been 
discussed in the past and around which consensus seems to have been 
reached, but on which we have yet to declare a final decision. By making 
a final decision as a community on a set of questions, further important 
questions about what will be in the specification can be more easily 
discussed (without having to consider the interaction with every 
possible other decision that is still open).

There has recently been some discussion over the best process to make 
decisions on specification related proposals. Although the exact details 
of the process still has to be worked out, there was agreement (at least 
amongst people in Auckland) that we should make decisions by unanimous 
agreement where possible, and only fall back onto some other process 
where this has been shown not to be possible. The process for 
determining such unanimous agreement seems to be to that the issue is 
proposed, discussion on the proposal takes place, and when this 
discussion dies down and there is an apparent consensus, community input 
is sought, and a deadline (sufficiently far in the future) for 
objections is provided. In the event that no objections are raised by 
the expiry of the deadline, the decision has been made. Objections could 
relate to the substance of the proposal, or simply be to request more 
time for the decision to be made.

So that the list of decisions I identified can be made, I have set a 
deadline of one week from now, that is, Wednesday March the 12th, at 
00:00:00 GMT (which is March 12th, 1:00 pm in NZDT). If you feel that 
this is not enough time, please make a note of this on the tracker item, 
including when you think the deadline should be, before the expiry of 
the March 12th deadline, so that the decision won't be made without your 
input.

The list of tracker items with my summary of them follows. If you are 
interested in discussion on these issues, please add yourself to the CC 
list for the individual tracker item concerned (you will need to create 
an account on the tracker if you don't have one already, but this is a 
process which anyone can do).

Tracker item 312 
(https://tracker.physiomeproject.org/show_bug.cgi?id=312) - proposal is 
that in the spec, we call individual CellML 'files' CellML Infosets, and 
we call all the files together 'CellML Models'.
Tracker item 319 
(https://tracker.physiomeproject.org/show_bug.cgi?id=319) - Proposal is 
that names like _1a be treated as valid CellML identifiers (fixes a 
conflict in CellML 1.1)
Tracker item 167 
(https://tracker.physiomeproject.org/show_bug.cgi?id=167) - Proposal is 
that imports create an instance of a model, and so it is invalid to 
import the same component twice in a single import element.
Tracker item 193 
(https://tracker.physiomeproject.org/show_bug.cgi?id=193) - Proposal 
about when we change namespaces on elements and when we keep the 
namespace from the previous version.
Tracker item 331 
(https://tracker.physiomeproject.org/show_bug.cgi?id=331) - Proposal is 
that RDF/XML inside extension elements should only contain extension 
specific metadata.
Tracker item 332 
(https://tracker.physiomeproject.org/show_bug.cgi?id=332) - Proposal is 
that we should allow references to secondary specifications which narrow 
down CellML to a specific type of problem (resolves issues relating to 
the CellML Subset in CellML 1.1 and the fact that the core CellML is too 
general to be fully implemented).
Tracker item 56 (https://tracker.physiomeproject.org/show_bug.cgi?id=56) 
- That we consider the issues arising from the CellML subset resolved 
(conditional on tracker item 332)
Tracker item 84 (https://tracker.physiomeproject.org/show_bug.cgi?id=84) 
- Proposal for a standardised real number format using a decimal point 
(as opposed to a decimal comma or decimal momayez).

I haven't included tracker item 337, about removing directionality from 
connections, because discussion on it seems to have stagnated without 
reaching agreement on the details of the best approach.

Best regards,
Andrew