...
Changing the OpenMI Standard has major implications for both OpenMI developers and users. Unfortunately, it is impossible to make such changes backwards compatible. Consequently, when a new OpenMI Standard is released, all model providers must upgrade their models to stay compliant with the latest OpenMI version. The pace at which this happens varies from model provider to model provider, since many model providers only make new releases of their software products on a six month or yearly basis. Hence, after an OpenMI Standard release it can often take a year before the bulk of compliant models are upgraded to the new version. This has implications for the OpenMI users, as they may find that the models they want to use for linked configurations are not compliant to the same OpenMI versions. For this reason a very conservative release strategy for the OpenMI Standard must be adopted. Of course this has to be balanced against the need to implement the change requests from developers and users. If the Standard stays unchanged for too long, variants of the standard will emerge. It is then unlikely that models compliant with such variants will be linkable to models that comply to the official OpenMI Standard, with the result that end users may find that there are supposedly OpenMI compliant models that cannot be linked.
Given all the considerations above, a time period of about two years between OpenMI standard releases seems appropriate. Such a long period between releases puts huge demands on getting the release right both with respect to quality and contents. Rigid procedures must be applied in order to ensure that releases are absolutely bug free and that the content - the functionality the standard provides - meets both current and future demands.
It is important that the procedure of upgrading the OpenMI standard is as open as practically possible. At all stages during the release all documents should be public available and it should be possible for anyone to comment and influence the decisions.
The new OpenMI Standard release is formally not developed by the OpenMI association. Anyone can provide proposals for OpenMI Standard version x+1. However, it is the right and responsibility of the OpenMI Association Executive Committee to select the best proposal.
...
The OpenMI Standard release schedule is divided into four periods:
1. OpenMI Standard x+1 change requests period
The change request period starts immediately after the release of OpenMI standard version x. During this period anyone can submit change requests to the standard. Change requests are submitted electronically on the OpenMI web and made public available. Change requests must follow the rules described below in the change request section. The OpenMI Association will within five days after submission of a change request accept or reject a change request (Michiel: Previous and next sentence may require slight rephrasing: Within 5 days the OATC will analyse the change request with respect to (a) procedures follows (b) factual relevance to the standard (not to the SDK or anything else), communicate the result of this analysis, and if the change request fullfills the requirements, list it in the offical OpenMI standard change request section (or something similar). ). Acceptance at this stage only means that the request follows the rules for change requests and that the request relates to the OpenMI Standard (many people are confused about the distinction between e.g. the standard and the SDK). So accepted change requests are not guaranteed to be included in the next OpenMI Standard. Acceptance of change requests will be (somehow) marked on the request on the web. If a request is rejected is will be marked on the web as rejected and the reasoning for rejection is given. If the person submitting a rejected request does not agree on the rejection, the rejection can then be appealed and a final decision will be made at the next OAEC meeting. The collection of incoming change requests will be discussed at every OAEC meeting and when appropriate the end date for submission of change requests (the end of the change request period) will be decided and announced on the OpenMI web. There must be at least a period of three months from the announcement of this date until the date actually occurs. After the end of the change request period the possibilities for on-line submission of change requests on the web is closed. The OpenMI web will also feature a facility for posting comments to change requests.
...
This period starts with a call for OpenMI Standard version x+1 proposals. The deadline for submission of proposals is also announced. The proposal period must be at least 4 months. Anyone can submit proposals (it can easily happen that OATC is the only one submitting such proposals, but to make the procedure as open as possible it should be allowed for anyone to provide proposals). As opposed to the change requests, that typically is aimed at one particular feature, proposals must describe the whole Standard. Proposals must be based on the change requests, but there is no limit to how many change requests that will be taken into account or to which extend the proposed standard reflects these change requests. The OpenMI Standard proposals must follow the requirement for such proposals (see Rules for OpenMI Standard proposal requirement below). Proposals are submitted online and will be public available. (What if a change request is not followed by a proposal? E.g. a change request from a non-IT specialist could basically be a request for supporting some functionality! Who is prioritizing the change requests? What do we do if everybody agrees that some functionality must be included, but nobody wants to put the efort in the desin? Maybe unlikely, but anyway))
3. OpenMI Standard x+1 commenting period
...
When the commenting period has expired the OpenMI Executive Committee will decide which proposal is favorable (in case multiple designs have been submitted?). The executive committee will take into account the submitted change requests, the Standard proposal and the comments to this proposal. The evaluation will be carried out according to the OpenMI standard proposal guidelines, which also are publicly available. The OAEC will announce on the web which proposal is selected and reference selected comments from the commenting period that should be taken into account. (The OAEC is not allowed to give new comments at this stage). The authors of the winning proposal will then respond whether they, under those conditions, will elaborate the final release candidate. If they accept then this will be announced and the test and documentation starts. (Test and documentation is carried out by those who submitted the winning proposal). The authors of the winning proposal will then make modifications to the proposed standard according to the comments, write documentation and test according the requirements for documentation and testing (see below). Finally the release is submitted and the OAEC can, if the everything is OK, release the OpenMI Standard version x+1.
If the submitters of the winning proposal decline to complete the OpenMI Standard release under the given conditions, the OAEC can decide to select another candidate or decide to delay the release. In case of the latter the whole release procedure starts from the beginning again (with a new change request submission period). Previous accepted change requests will still be valid.
...
Since the OpenMI standard simply is implemented interfaces, real unit test cannot be applied to the interfaces themselves. Hence, the purpose of the test is to ensure that things possible with the previous release also are possible with the new release (and in case not, make a sufficient argumentations for why that is). Make sure that features anticipated for the new release actually can be realized.
Specifically the test must involve the following:
...
Only in-code xml comments are required.
asdfasdf