| scrollbar |
|---|
See also: OATC Wiki Home
Date: July 1, 2010
Time: 09:00 - 10:30 am
Venue: Skype Conference Call
Topic: Extendable version of OpenMI 2 (continued)
...
Rob Knapen, Alterra, Wageningen UR (Rob.Knapen@wur.nl)
Standa Vanecek, DHI (s.vanecek@dhi.cz)
Adrian Harper, Wallingford Software (adrian.harper@wallingfordsoftware.com)
Stef Hummel, Deltares (stef.hummel@deltares.nl)
~don, Deltares (gennadii.donchyts@deltares.nl)
~jgr@dhigroup.com, DHI (jgr@dhigroup.com)
Peter Schade, Bundesanstalt fuer Wasserbau (peter.schade(at)baw.de)
Apologies:
Unknown User (don), Deltares (gennadii.donchyts@deltares.nl)
1. Progress towards OpenMI 2 Beta release
...
(Rob) No updates have been made since about two weeks, due to lack of time. Current source code is out-of-sync with C# version and needs to be updated. Looking for a volunteer to do this since I will be attending the iEMSs in Ottawa and not have time until mid July.
todo: Stef will take care about the Java documentation before the iEMSs conference on the 5th July.
1.3. Documentation updates
(Peter) Suggestion: Until 9. July mainly specify the IBaseLinkableComponent and a small general explanation of the Time+Space extension. The full Time+Space specification should follow after the sdk has been updated and tested.
(Stef) Maybe keep the documentation more or less as is, and only clearly describe the 'base' - 'timespace' leveling.
...
Probably also the configuration editor should be build in a 32 bit and 64 bit version.
todo:
- An attribute, something like "Processor_Architecture" should be added to XML file ( Windows, Linux, 32bit, 64bit, ...)
- A pure 32bit and a pure 64bit version will be generated.
to discuss in the future:
- A manifest of file dependancies should be added.
2) An input item can only take one output (one provider).
...
Also in this context, the IAdaptedInput would come in handy.
- maybe later
1) ITimeSpaceValueSet.PreferedOrderIsElements property
(Jesper) This does complicate quite some things. It is not fully supported in the SDK. As we have now moved the property into a "TimeSpace" extension, I would vote for removing it again, assuming Values2D is ordered with time first.
This type of component related flag, indicating the order of time and elements, is not needed.
2. Ongoing discussion topics
2.1. Note about OpenMI 2 compliancy
...
2.1.1. Formal compliancy definition
The flexibility of OpenMI version 2 can be recognized in the compliancy definition. The compliancy refers to a set of basic interfaces as well as to optional extension interfaces, e.g. for time and space dependent components. The IBaseLinkableComponent is the key interface.
OpenMI-compliance definition:
1. An OpenMI-compliant component must implement the IBaseLinkableComponent interface according to the specifications provided as comments in the OpenMI.Standard2 interface source code.
2. An OpenMI compliant component can also comply to one ore more extensions, by implementing the IBaseLinkableComponent interface and the extension interfaces which it wishes to comply to, according to the specifications provided as comments in the OpenMI.Standard2 source code.
3. An OpenMI-compliant component, optionally with extensions, ...
Alternative. 3a ... must, when compiled, reference the OpenMI.Standard2*.dlls/jars, which are released and compiled by the OpenMI Association.
Alternative. 3b ... must reference the OpenMI.Standard2 namespace, which is released by the OpenMI Association. 
4. An OpenMI-compliant component must be associated with an XML file, the so called
OMI file, which complies to (can be validated with) the LinkableComponent.xsd schema.
5. An OpenMI-compliant component must be associated with an XML file, which complies to (can be validated with) the OpenMICompliancyInfo.xsd schema. This file must be submitted to the OpenMI Association.
6. The OpenMI Association provides two additional interfaces that OpenMI-compliant components may or may not implement: the IManageState interface and the IByteStateConverter interface. However, if these interfaces are implemented, each method and property must be implemented according to the comments given in the OpenMI.Standard2 interface source code.
7. The OpenMI Association's downloadable standard zip file provides the only recognized version of source files, XML schemas and assembly files.
* at 2.: This leads to a main difference between OpenMI 1.x and OpenMI 2. In order to become 1.x compliant the classical time and space dependent component just had to implement the ILinkableComponent interface. This component now would have to implement the basic interfaces and the time and space specific extension for becoming OpenMI 2 compliant.
2.1.2. What does the compliancy definition mean for the user?
...
4. Are all required output adapters implementations compatible. Version 2 allows for adapters tailored for specific applications and hence some combinations could be invalid. Whilst it can be reasonably expected that adapter implementations from the same software source (SDK) should either be compatible or create sensible runtime warnings if not (if developed well). This is unlikely to be the case when mixing adapters from different software sources. Hence, when using output adapters care should be taken to understand their implementation details."
todo: add the points to the list of compliant models on the OpenMI website.
2.2. How to package and distribute extensions
...
(Jesper) I believe (at least for C#, I am not sure with java) when we first have released the OpenMI2.Standard.dll, then there are issues in case this dll is updated to include e.g. a dictionary extension: Two different OpenMI2.Standard.dll files having the same version number, but different content. It would be much more safe to release an OpenMI2.Standard.DictionaryExtension.dll, and leaving the original content in the OpenMI.Standard.dll. It may be possible to put it all in a new standard dll, however that requires "intelligent" installers: Assume I am to install a TimeSpace engine and a Dictionary engine, which come with each their version of the OpenMI2.Standard.dll that they want to install and register in the GAC. Depending on the order in which I install the engines, each installer needs to know whether they are to reregister their version of the OpenMI2.Standard.dll in the GAC, to assure that the newest version is the one registered.
2.3. Revisit discussions left out from meeting 29
Documentation Tasks
Document | Update? | update author | author deadline | reviewer | deadline |
|---|---|---|---|---|---|
What's new in OpenMI 2.0 | yes | Stef, Peter | 5. July | who | 9. July |
OpenMI 'in a nutshell | yes | Adrian, Rob | 5. July | who | 9.July |
Scope document | y/n | who | - | who | - |
The OpenMI Standard2 interface specification | yes | Stef, Peter | 7. July | who | 9. July |
Migrating models | yes | Jesper | - | who | - |
Standa made a Word *.doc out of the reviewers' feedback. The suggestions that have been integrated in OpenMI 2 will be indicated. The new document will be put on the wiki / www.openmi.org in order to display that the feedback was indeed valuable.
2.4. Revisit discussions left out from meeting 28
There is a number of discussions there, that has not yet been decided on.
Remove GetHashCode() and Equals() overrides in Backbone package
Similarly, the DescribeSameAs functions are a bit unclear: When does a quantity describe the same as another, which properties should match: description, unit (with description, caption, dimension and conversion factor) or dimension.
Suggestion to make utility functions in the SDK that can do the comparison on the required level and remove the DescribeSameAs methods.
Alternatively, the DescribeSameAs should be precisely documented.
Make IAdaptedOutput implement IInput
maybe later -> a candidate for the wishlist
Generic versions of exchange items and valueset
Cons: It adds complexity to the standard (A standard developer may not have/do not want to bother about this level of skills), and it is specific to java and .net.
pros: It adds more type safety to the code, and also some performance.
maybe later -> a candidate for the wishlist