Page History

...

1. The Timezone issue has been re-adressed.
   Discussion/Conclusion led to the following decisions :
   1. Daylight Saving Time jumps in time series are not allowed
   2. The TimeSet will contain a property that expresses its offset from UTC, expressed in hours (OffsetFromUtcInHours). The Gui will check these offsets, and if they are different, it will ask the user to put a decorator in between. The offset has to be applied to both the timeSet's Times and its TimeHorizon.
      Note: in future and/or more platform specific versions of the standard we may reconsider introducing the timezone info again.

...

• Decorator issues, other:
  • Is is useful to let the component have a property OutputDecorators, containing the list of already created decorators? For now, we will stick to the "keep it lean and mean" principle. As soon as it is really clear that it is needed (action Gena) it will be added.
    Gena: example added here: OutputItemDecorators property in ILinkableComponent
    All Oatc members should have a look at it, and give their opinion as soon as possible.

• IArgument needs a mechanism for identifying the type of argument e.g. File, Path, int double etc Very usful for providing customised GUI functionality
  Various solutions were proposed (see below). Disadvantage of having an enumeration in the Standard is that it can not be extended easily. An object type definition would be more specific.
  Rob K. concludes that Alterra's approach works quite well for what we want. The approach is based on recognized strings in the key of the Argument.
  Action: Rob K. will provide an example.
  Done June 10: Please see the IArgumentV2.java class file that I have attached to these meeting notes. This interface documents all the extensions we made to standard OpenMI 1.2 IArgument interface to make it more usable for our (GUI related) purposes (some time ago). The comments in the source file should provide all the explanation needed
  We have studied the example and various propositions, and choose for to the following solution (to be documented yet) .

...

1. Suggestion by Gena on pull / loop approach
   Discussion/Conclusion: A good idea to introduce the GetValues, to recognize the pull approach. However, instead of on the LinkableComponent, for now it has been put on the output item (see above). If it turns out to be more logical to be on the LinkableComponent, we may move it there. To be considered at next meeting .

  // =================================== pull approach

  var triggerExchangeItem = component.OutputItems[0];
  triggerComponent.GetValues(triggerExchangeItem);


  // =================================== loop approach

  while(!allComponentsAreFinished)
  {
      foreach(var component in components)
      {
          if(component.Status != LinkableComponentStatus.Finished)
          {
              component.Update();
          }
      }
  }

  public interface ILinkableComponent
  {
      LinkableComponentStatus Status { get; }
      void Initialize();
      void Validate();
      void Update();
      void Finish();
      IList<IInputItem> InputItems { get; }
      IList<IOutputItem> OutputItems { get; }
      bool CascadeUpdateCallsDisabled { get; set; }

      // Suggestion: ask for specific values: e.g. filtered data
      IList GetValues(IInputExchangeItem query);

  }

...