| scrollbar |
|---|
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)
...
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 Unknown User (don), Deltares (gennadii.donchyts@deltares.nl)
Jesper Grooss, DHI (jgr@dhigroup.com)
Peter Schade, Bundesanstalt fuer Wasserbau (peter.schade(at)baw.de)
...
Add property to indicate lengths of the dimensions to IValueSet
Wiki Markup GetIndexCount(int\[\] indices)}} are:
| Code Block |
|---|
/// <summary> /// Returns the length (max index count) of the dimension specified by the /// given indices. To get the size of the first dimension, use a zero-length /// integer array as input argument. Length of indices must be a least one /// smaller than the <see cref="NumberOfIndexes"/> /// </summary> /// <param name="indices">indexes of the dimension to get the length of</param> /// <returns>length of the specified dimension</returns> |
...
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 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.
Decision 
: We choose for the second description, including the rephasing of Jesper
2.1.3. What does the compliancy definition mean for the user?
...
| Code Block |
|---|
IBaseLinkableComponent { base methods };
ITimeSpaceLinkableComponent extends IBaseLinkableComponent { time-space methods };
IParallelLinkableComponent extends IBaseLinkableComponent { loop methods };
IDictionaryLinkableComponent extends IBaseLinkableComponent { dictionary methods };
MyParallelTimeSpaceComponent implements ITimeSpaceLinkableComponent, IParallelLinkableComponent {};
MyParallelDictionaryComponent implements IDictionaryLinkableComponent, IParallelLinkableComponent {};
|
3. New discussion topics
Decision : We keep the exchange items as an hierarchy, and will use alternative 2 for the linkable components, together with combined empty interfaces mentioned at the previous meeting:
| Code Block |
|---|
ITimeSpaceLinkableComponent : IComponent, ITimeSpaceLinkableComponent {};
|
3. New discussion topics
3.3.1. How to package and distribute extensions
...
(Jesper) It was discussed in the last meeting to add extra events to the TimeSpaceExchange item to keep track of when the timeset and elementset changed. I would suggest to put these directly on the ITimeSet and ISpatialAxis/IElementSet instead. Especially, for the ISpatialAxis/IElementSet it could also be nice with a property bool IsDynamic, to indicate wether the ISpatialAxis/IElementSet can change at all.
Decision 
: Could lead to a managemanagement problem (keeping track of all listeners).
3.3. Revisit discussions left out from meeting 28
There is a number of discussions there, that has not yet been decided on.
3.
...
4. Should an ITimeSpaceLinkableComponent override some of the IBaseLinkableComponent methods:
(Jesper) Currently an ITimeSpaceLinkableComponent provides its inputs and outputs as IBaseInput and IBaseOutput. Are these always transferable to ITimeSpaceInput and ITimeSpaceOutput, or could there be cases where other types of inputs and outputs are suitable? Would we even allow that? It could be considered to add methods to the ITimeSpaceLinkableComponent like:
...
That would require all inputs and outputs to be of type ITimeSpaceInput and ITimeSpaceOutput. I guess that would make it difficult to make an ITimeSpaceDictionaryComponent, combining the TimeSpace and the Dictionary extension, since they would each require a different type of their inputs and outputs lists.
Decision : Avoid too specialized components.