Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

3.1.1 Changest to the standard

  • Time interfaces, according to suggestion I, see Section 3.6.1
  • Elements - HasZ, HasM ....
  • Decorator - Factory,....
  • Keep, Save and Clear state, convert to/from byte[] to make persistent

...

  • IIdentity has been split in IIdentifiable and IDescribable. Some interfaces already have been derived from IIdentifiable and/or IDescribable** (question) At some stage, we should check all interfaces on whether to derive from IIdentifiable and/or IDescribable or not.
    • (thumbs up) At this meeting, we have checked that IIdentifiable and/or IDescribable are not used as seperate entities.
  • IArgument needs a mechanism for identifying the type of argument e.g. File, Path, int double etc Very usful for providing customised GUI functionality
    • (question) Adrian's proposal is below
      • Code Block
        namespace OpenMI.Standard
        {
            public enum EArgType
            {
                String = 0, // default
                Bool,
                Int,
                Double,
                Path, // presummed to exist and accessable
                FilePath, // presummed to exist and accessable
                PathNew,
                FilePathNew,
                XML, // Rob: can be used together with a schema for complex argument data
                MIME, // Rob: might be useful to pass in images, or text documents, etc.
            }
        
            /// <summary>
            /// The IArgument interface defines a key - value pair. If the property ReadOnly is
            /// false the value is editable otherwise it is read-only.
            /// </summary>
            public interface IArgument : IDescribable
            {
                /// <summary>
                /// Type that string value represents and can be converted to
                /// </summary>
                EArgType ValueType { get; }
        
        	/// <summary>
                /// The key (string) in key-value pair.
        	/// </summary>
        	string Key {get;}
        
        	/// <summary>
                /// <para>The value (double) in key-value pair.</para>
                ///
                /// <para>If the ReadOnly property is true and the property is attempted to be changed
                /// from outside an exception must be thrown.</para>
        	/// </summary>
        	string Value { get; set; }
        
        	/// <summary>
                /// Defines whether the Values property may be edited from outside.
        	/// </summary>
        	bool ReadOnly {get;}
            }
        }
        
  • Using empty Temporal and ElementSet in the Input items.
    See http://public.wldelft.nl/display/OPENMI/Empty+Sets+in+the+Input+Items+-+Element+set+changing+in+time
  • Changing of the ElementSet during the time and different Times (steps) for different Elements
    • For the Time can be probably solved by missing values

3.6 The ITime Issue

Anchor
timeInterfaces
timeInterfaces
3.6.1 Time Interface(s)

After some discussions, their were four proposals. See list below (including the original 1.4 situation).
Note: naming to be done yet.

...

Code Block
java
java
titleOriginal 1.4 situation
  public interface ITime
  {
  }
  public interface ITimeStamp : ITime
  {
      double ModifiedJulianDay {get;}
  }
  public interface ITimeSpan : ITime
  {
      ITimeStamp Start { get; }
      ITimeStamp End   { get; }
  }

After studying the proposal, we have made a decision (thumbs up). We will take version I.

Anchor

...

timeAsMJD

...

timeAsMJD
3.6.2 Platform specific time or Modified Julian?

Adrian suggested that we incorporate as less platform specific things in the Standard as possible. This also holds for Lists and events. (question) We will be put the issue on the agenda for next meeting.
After some detailed discussion on the .Net.DateTime/Java.Date versus the MJD implementation, we have reached a conclusion (thumbs up) : We will keep using the Modified Julian Day.
We should take into consideration whether we want to support a c++ version of the standard in the future.

...