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.

...

- 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 A manifest of file dependancies should be added.

2) An input item can only take one output (one provider).

...

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.

The This type of component relating flags (related flag, indicating the order ) are 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?

...

todo: add the points to the list of compliant models on the OpenMI website.

2.2. How to package and distribute extensions

...

2.3. Revisit discussions left out from meeting 29

todo: Peter have a look at

Documentation Tasks

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

...

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.

Decision: put it to the utilities

Make IAdaptedOutput implement IInput

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 wishlistWill be looked at later

3. New discussion topics