Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin
scrollbar

See also: OATC Wiki Home

Date:

...

November 3-5, 2008
Venue: Deltares, Rotterdamseweg 185, Delft, The Netherlands

...

Jan Gregersen, DHI / LicTek (gregersen@lictek.dk) (chairman of the meeting)
Adrian Harper, Wallingford Software (adrian.harper@wallingfordsoftware.com)
Stef Hummel, Deltares (stef.hummel@deltares.nl)
~don Unknown User (don) (Gena), Deltares (gennadii.donchyts@deltares.nl)
Andrea Antonello, Universita` di Trento, (andrea.antonello@gmail.com)
~onnoroos Unknown User (onnoroos), Alterra (Onno.Roosenschoon@wur.nl)
Peter Gijsbers, Deltares (Peter.Gijsbers@deltares.nl)

...

Minutes:
The minutes from the last OATC meeting was were accepted

2. Maintenance and support

...

Minutes:
No changes, seems we are doing well with respect to providing answers to questions. It was notified that now also people outside the OATC group are providing answers, which is highly appreciated.

...

Minutes:
The use cases were not consulted at this meeting. We will make a detailed review of the use cases at the next meeting, when the draft OpeNMI OpenMI 2.0 architecture is in place in order to check if we covered the functionality defined by these use cases.

3.2 OpenMI 2.0 architecture

3.2.1 Current status

The current OpenMI Standard interfaces a before the meeting are shown in the figure below. The implementation is located in the trunk on source forge.

Minutes: ToDo

3.2.2 Events

At the last meeting we discussed if we adapt the way events are used in C# rather that using our own implementation.

See page : Use standard events instead of many interfaces like IListener, IPublisher

Minutes: ToDo
Gena presented his ideas and it was decided that Gena will add events and event args in the standard,
add unit test for LinkableComponentt in backbone demonstrating the events, add log4net and show how to use it in the backbone.

3.2.3 Configuration interfaces

...

Minutes:
We decided not to rename the IValuesDefinition interface. Review We will review all interface names when we have the final draft version of the standard architecture ready.

3.2.5 Spatial issues

...

see Refactor ITime, ITimeSpan, ITimeStamp - use DateTime and TimeSpan in .NET and corresponding default types in Java

Minutes: ToDo
It was decided to use the C# types for date and time instead of the Modified Julian time. Gena will make the changes to the version 2 standard and SDK. There is still a question about whether we also should include time zones. We will look into this at the next OATC meeting.

3.2.7 IArgument

Comment by Jan: I think we need a more powerful argument interface. Such interface should facility different types such as doubles, strings, bool, and selection types. By selection types I think about situations where the user will select on or multiple options from a predefined list. At our last meeting the IDictionary interface was mentioned, but I have doubts that it will provide the functionality needed. Then I came to think about the functionality provided by XML schema files. E.g. for our OpenMICompliancy schema file a pretty complex data structure is well defined. However, I would prefer not to include schema files into the nice clean interfaces based standard, so maybe we can find a interface based solution that has the same functionality as a schema.

Minutes: ToDo
We investigated improving the IArgument interface. Gena will make a suggestion for the next OATC meeting.

3.2.8 Using Object to pass the values

...

Comment by Peter: In the design as presented before the meeting, the IInputExchangeItem has a Values-set property. I wonder if this is wise from a communication perspective. to outsiders. We want to pull-mechanism to remain the main focus of OpenMI components, such that they can easily be used in a service-oriented architecture. When introducing SetValues at the root level of an IInputExchangeItem, it is much more difficult to explain that we prefer usage of the pull-mechanism, but that some advanced applications may need this put mechanism. I would therefore recommend to move the Values-set property to a separate (derived) interface called IAdvancedinputExchangeItem. This makes explanation much easier, while we introduce less risk with components not being able to handle a set-value.
.
Minutes:
For the time being we will not make an advanced interface for setting values. Once we have the draft standard architecture completed and start documentation we will decide what to do. The main issue is to to find out what is easiest to explain, since it with respect to functionality will be more or less the same.

...

Comment by Peter: Finally, it becomes time for a persistent state. However, it might be wise to evaluate the experiences with the current state mechanism.
Minutes:
We agreed to a add an interface for persistent state management. Stef will implement the interface

...

Comment by Peter: The OMI file is a pragmatic method to instantiate a component. A Factory pattern should be considerd for the Standard, where the default implementation of the SDK is based on the OMI file.
Minutes: ToDo
We could not reach an agreement about using a factory pattern instead of the OMI file that is currently used in OpenIM 1.4. Stef and Peter will write at documents that i more details explains how the factory pattern will could work and some examples of situation where using the factory pattern is beneficial to the end users (those that create compositions). We will discuss the factory pattern again at the next OATC meeting.

3.3 Development and release road map

...

December 20th 2009
OpenMI 2 standard, SDK and GUI release.

Minutes: ToDo
There were no changes to the development roadmap. We are still on track..

3. OpenMI Java and OpenMI .net synchronization

Minutes: ToDo
No new issues here.

4. OATC Procedures

4.1 Proposal for procedures for OpenMI Standard releases

see: Proposed procedure for OpenMI Standard releases

Minutes: ToDo
This procedure will be discussed at the next OAEC meeting, no new comments from the OATC

4.2 Proposed procedure for evaluation of OpenMI compliance

see Proposed procedure for evaluation of OpenMI compliance.

Minutes: ToDo
The OpenMI compliantcy acceptance procedure will be discussed at the next OAEC meeting. In case this procedure is accepted by the OAEC, the OATC will recommned that Stef becomes the OpenMI Compliancy acceptance manager. Stef will review the proposed procedure and make changes or add comments to the wiki page where it is described.

4.2 Review and update the OATC procedures

...

(GOTO OATC procedures)

Minutes: ToDo
No changes to existing procedures.

5. www.OpenMI.org and wiki.OpenMI.org

...

A proposal to the OAEC is ready in a draft version: see OpenMI Association website proposal_MB.doc

Minutes: ToDo
We will await the OAEC decision.

6. Miscellaneous issues

6.3 Submitted OpenMI compliance XML's

...

Adrian will demonstrate the work done by Walling Software.
Minutes:
The OATC appreciates that HRW provides nice alternatives to the SDK and GUI provided by OATC.

7. Tasks and unresolved issues

...

h.4 Suggestion for changing the location for the next OATC meeting
*Minutes:
It was suggested to have the next OATC meeting (January 13-15 2009) in Trento, Italy. Andrea will check if Univertity of Trento will host the meetings and report back to Jan within a couple of weeks. If we decide to move the location of the next meeting, all already planned meetings will shifted accordingly .

h.4 The 1.4.1 SDK and GUI release
*Minutes:
Jan will check the reported bugs, and fix the bugs assigned to him. Then report back to Adrian, who will create a beta 1.4.1 beta version (around December 5th). The target is to release before end of 2008.

Plan from now until next meeting