...
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
...
When the commenting period has expired the OpenMI Executive Committee will decide which proposal is favorable. 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