Page History

...

Related to this: do we need void Update(params IOutputItem[] requiredOutputItems), or is void Update() enough? The alternative is that the consuming component(s) register/deregister input items to/from the output items that they want to be updated.
After some discussion we concluded that we need a relevant use case for this. Rob will create one in Java, Stef will port it to C#.
If we decide to keep it in, we should explain in detail how a time progressing component behaves when the optional argument is given indeed.

My vote is to keep it. Typical use case is to ask component for an update only of some specific items, think about it as a query. We can then test components independently from the rest. E.g. query values only for selected areas event when component can provide data for many areas.

IArgument.IsReadOnly

Is it really really needed? (Stef thought so, but does not consider it essential anymore).
The property is needed indeed. Given the values of other arguments, an argument may become readonly because it simply may not be changed in that situation.
Now, the initialation of a component will go like this:

...

• IlinkableComponent.Initialize(IArgument[] arguments) will be changed to IlinkableComponent.Initialize()

Gena:

IOutputItem.Consumers and IOutputItem.Decorators

...

Both the Consumers and the DerivedOutputItems preferably should be implemented as readonly lists.

Gena: I find it redundant, if you can add and remove consumers, why not to keep it IList - it can add and remove and count things. My vote is for either:

Code Block
public interface IOutputItem { IList<IInputItem> Consumers { get; } IList<IDerivedOutputItem> DerivedOutputItems { get; } }

or:

Code Block
public interface IOutputItem { IEnumerable<IInputItem> Consumers { get; } void AddConsumer(IInputItem consumer); void RemoveConsumer(IInputItem consumer); IEnumerable <IDerivedOutputItem> DerivedOutputItems { get; } void AddDerivedOutputItem(IDerivedOutputItem derivedOutputItem); void RemoveDerivedOutputItem(IDerivedOutputItem derivedOutputItem); }

However in the later case performace may be an issue in remote scenarios - you'll have to iterate via the whole enumeration in order to get a single element or to compute Count().

Minor comment: IDerivedOutputItem sounds less explicit than IOutputItemDecorator. The later one decorates a single output item.

Terminology

• Name space: after some discussion we decided to change the name space to OpenMI.Standard2.
  The reason to do this, is to facilitate 1.4 model wrapping
• Are we sure that we want to use the name IOutputItemDecorator instead of the well known name IDataOperation?

Gena: no preferences, extept that from the name IDataOperation it is not clear that it is used for Output item. Should be at least IOutputDataOperation.

After some discussion a few suggestions are at the table in the table below.

Gena: ... it does not sound more explicit than Decorator, the word Derived is more generic compare to Decorated. My suggestion is to keep it as it is unless there are good arguments and examples why it should be changed.

I'd keep the word Item in anyway, then it is clear what we work with one item here. Meaning of the word Output feels much wider compare to IOutputItem (output can be a set of all model output items).

• We should rename either IOutputItemDecorator.Update() or ILinkableComponent.Update() (or both).
  (Note: during the discussion on the latter, it appeared to be unclear if of IOutputItemDecorator.Update() should at its turn call its own decorators' Update functions. This is the case indeed. Jesper has stated this more explicitly in the documentation.
  After an extremely short discussion we choose Rob's suggestion: IOutputItemDecorator.Refresh()

Gena:

SDK

The original packages in the 1.4 SDK are not that explitely identifiable in 2.0. Besides of that, more then one model wrapping utility has been developed (by Adrian and by Stef/Jesper), so we should determine what to put in which package.
Other things that to take care of:

...