You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Next »

See also: OATC Wiki Home

Date: June 25, 2010
Time: 10:00 - 11:30 am
Venue: Skype Conference Call
Topic: Extendable version of OpenMI 2 (continued)

Table of contents

Participants

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)
Jesper Grooss, DHI (jgr@dhigroup.com)

1. Progress towards OpenMI 2 Beta release

1.1. Source code updates

1.2. Documentation updates

2. Ongoing discussion topics

2.1. Note about OpenMI 2 compliancy

(Peter) To be decided: which compliancy is more appropriate?

(Rob) I prefer the second option. However besides stating when something is compliant, I think we should also make it more clear what this means in practice for the average modeler / user.

2.1.1. Slightly changed from 1.4 compliancy

The IBaseLinkableComponent is the key interface in the OpenMI standard version 2. Any OpenMI compliant component must implement IBaseLinkableComponent.
OpenMI-compliance definition:

1. An OpenMI-compliant component must implement the IBaseLinkableComponent interface according to specifications provided as comments in the OpenMI.Standard2 interface source code. *
2. An OpenMI-compliant component must, when compiled, reference the OpenMI.Standard2.dll, which is released and compiled by the OpenMI Association.
3. An OpenMI-compliant component must be associated with an XML file, which complies to (can be validated with) the BaseLinkableComponent.xsd schema (same information a 4. - leave it out?)
4. 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.
5. 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.
6. The OpenMI Association's downloadable standard zip file provides the only recognized version of source files, XML schemas and assembly files.

* at 1. The OpenMI Association provides extensions to the standard with more specific interfaces, e.g. for time and space dependent components. Although these extensions are part of the standard they are formally not required for compliancy. But the OpenMI Association recommends to implement the appropriate extension for easier data exchange with other OpenMI compliant components.
This means a change in the implementation of the classical time and space dependent component, which had in 1.x  just to implement the basic ILinkableComponent. For OpenMI 2 compliancy this component would have to implement the basic and the time and space specific extension interfaces.

2.1.2. Two level compliancy

The compliancy with the OpenMI 2 standard is split into two levels. The OpenMI compliancy on the first level refers to basic interfaces whereas the OpenMI extension-compliancy includes additional interfaces, e.g. for time and space dependent components.

The IBaseLinkableComponent is the key interface in the OpenMI standard version 2.

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 extension-compliant component must implement the IBaseLinkableComponent interface and at least one of the extension interfaces according to the specifications provided as comments in the OpenMI.Standard2 interface source code. *
3. An OpenMI-compliant as well as an OpenMI extension-compliant component must, when compiled, reference the OpenMI.Standard2.dll, which is released and compiled by the OpenMI Association.
4. An OpenMI-compliant as well as an OpenMI extension-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.
5. 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.
6. 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 basic ILinkableComponent. This component would have to implement the basic and the time and space specific extension interfaces for becoming OpenMI 2 compliant.

2.2. How to define the extension interfaces

(Rob) Still considering the two approaches: using a hierarchy (i.e. ITimeSpaceLinkableComponent extends IBaseLinkableComponent, MyComponent implements ITimeSpaceLinkableComponent) or composition (i.e. MyComponent implements ILinkableComponent, ILinkableComponentTimeSpaceExtension). Should consider the effect when adding a linkable component interface for the loop method(s) or for the FRAMES dictionary support. Also see how OGC spatial element sets can be added as an extension and how this effects the interfaces.

Alternative 1 (interface hierarchy):

IBaseLinkableComponent { base methods };
ITimeSpaceLinkableComponent extends IBaseLinkableComponent { time-space methods };
IParallelTimeSpaceLinkableComponent extends ITimeSpaceLinkableComponent { loop methods };

IDictionaryLinkableComponent extends IBaseLinkableComponent { dictionary methods };
IParallelDictionaryLinkableComponent extends IDictionaryLinkableComponent { loop methods };

MyParallelTimeSpaceComponent implements IParallelTimeSpaceLinkableComponent {};
MyParallelDictionaryComponent implements IParallelDictionaryLinkableComponent {};

Alternative 2 (uncoupled interfaces):

ILinkableComponent { base methods };
ILinkableComponentTimeSpaceExtension { time-space methods };
ILinkableComponentParallelExtension { loop methods };
ILinkableComponentDictionaryExtension { dictionary methods };

MyParallelTimeSpaceComponent implements ILinkableComponent, ILinkableComponentTimeSpaceExtension, ILinkableComponentParallelExtension {};
MyParallelDictionaryComponent implements ILinkableComponent, ILinkableComponentDictionaryExtension, ILinkableComponentParallelExtension {};

3. New discussion topics

3.1. How to package and distribute extensions

(Rob) When an extension is approved by OATC will it be included into the Standard library (dll or jar), or will each extension be distributed in its own library?

  • No labels

Disclaimer