[Moims-mp] MO Object requirements

Tue Aug 4 16:01:47 UTC 2020

Hi Sam,

Another observation from my MPS Information Model work.

In some cases, we want to be able to reference a specific attribute or argument of an MPS Object.  We could do this with just the Object reference, but it requires us to have some form of expression syntax to specify which attribute or argument.

It might be a reasonable extension of the MAL ObjectRef attribute type to allow the specification of an attribute or argument by name.  In other words, it should be able to support:

-          Reference to the Object

-          Optionally a reference to the specific Version of the Object

-          Optionally a named attribute or argument of the Object (the equivalent to dot notation in many OO languages, eg.  MyEvent.Argument1 or MyEvent.eventTime

A possible issue is that the type of the value returned by a simple ObjectRef would be a MAL::ObjectRef, but for a named attribute/argument it would be that of the attribute/argument (still a MAL::Attribute).

We have our current MPS Information Model the concept of an “expression” – a text string that can be evaluated to give a result of a particular type.   The expression syntax is not specified as part of the standard, to allow any standard or bespoke syntax to be used.  However, there are two areas where there are specific requirements on what should be supported by the language, and where we may provide a default syntax as part of the standard.  One of these is Object Expressions.  The following is our current set of requirements for Object Expressions (modified to remove references to the COM related and source links):

The syntax for Object References must support the following:

- References to Planning Events, Planning Activities, Planning Requests, Plans and Planning Resources

- References to any Attribute of Planning Events, Planning Activities, Planning Requests, Plans and Planning Resources

- References to any Argument (by name) of Planning Events, Planning Activities and Planning Requests

- References may be via:

                - Name [ObjectID]

                - The current object (by context) "Me"

                - An Object referenced in an argument or attribute of another Object, including its Definition or Source/Parent.

                - A Child Object of another Object by Name

                - A Sibling Object (another child of the parent [source] object by Name

Note that Child and Sibling relationships apply only to Planning Events and Planning Activities.

Note that Name identifies a Planning Resource explicitly, but only the Definition class of Planning Activities and Planning Events.  These references must be resolvable at run time to a specific Instance, based on context.

It strikes me that many of these requirements would be satisfied by a MAL::ObjectRef that could reference attributes/arguments (recursively where the attribute/argument is itself an ObjectRef – eg.  MyActivity.relatedEvent.eventTime ).  Child and Sibling relationships are more complex, requiring the ability to specify the member of a set with a specified Name:  eg. MyActivity.children(“MyChild”) [the child Activity of the referenced Activity called “MyChild”] and MyActivity.source.children(“MySibling”) [the child Activity of the parent of the referenced Activity called “MySibling”].

If these requirements were satisfied by MAL::ObjectRef, we would not need to specify an Object expression syntax.

It may be one step too far for you, but worth considering.

Cheers,

Roger

From: Roger Thompson [mailto:roger.rocketbrain at btinternet.com] 
Sent: 13 July 2020 12:23
To: 'Sam Cooper'; 'Stefan Gaertner'; 'Churlaud Olivier'; 'Cesar Coelho'; 'Dan Smith'; 'Radulescu, Costin (3900)'; 'Dominik Marszk'; 'Coelho, César'
Subject: RE: MO Object requirements

Hi Sam,

Some observations from my current activity looking at how the MPS Model will be simplified by the [assumed] changes to COM and MAL.  I have so far only looked at some of our core Object types (Planning Activities, Planning Requests and Planning Events) in any detail – we also have Plans and Planning Resources that may have different characteristics.

FYI, I have assumed 3 new attribute types in MAL:

·         MAL::ObjectID  - but this might be harmonised with MAL::Identifier

·         MAL::Version for objects that are versioned (such as definitions, and potentially Planning Requests) – this could be integrated into the ObjectID attribute type

·         MAL:ObjectRef – a reference to another MO Object, where I have assumed this supports a reference to the Object and optionally its Version.

We previously used 3 COM object patterns in MPS:

·         2 COM objects: Identity + Definition  for things that only had static definition data

·         3 COM objects: Identity + Definition + Update for things that have a static definition and dynamic value/status, such as Parameters or in our case Planning Resources

·         4 COM objects: Identity + Definition + Instance + Update for things that have a static definition with discrete run-time instances and dynamic value/status for these, such as Planning Activities and Planning Events.

I believe the simplified model results in removal of the Identity objects, and the treatment of Updates as a structure, not an object.  

The update structure includes an ObjectRef pointing to the MO Object, and a timestamp, plus all dynamic attributes of the object.

There may also be a need for a structure to capture the static attributes of an object (including its ObjectID and Version) if the object has a mixture of static and dynamic attributes – this is what would appear in configuration data.

The MO object patterns become:

·         1 MO object:  static definition only

·         1 MO object:  static definition + dynamic value/status, with a separate Update structure

·         2 MO objects: definition object (static attributes only); instance object (static + dynamic attributes) with separate Update structure for the latter.

We had a complication for Planning Requests as these have optional definitions and can also be updated.  Previously we had to separate the Planning Request Template (2 COM objects) and Planning Request (3 COM objects) as separate things.  This can be reduced from 5 to 2 MO objects (Definition and Instance), but as the Instance is updateable, both are versioned.

This is all compatible with what you propose, but I have the following observations:

1.      Some of our ObjectRefs are not to a unique Object type:  forcing this may mean we need to define additional (unnecessary) object types or structures.  A case in point is Planning Resources, where we require different definition sub-types for Numeric, Status and String type resources, but the updateable value is always a MAL::Attribute.  Previously we had to specify multiple Update objects to support a one-to-one Related link to their definition.  If ObjectRefs have to be strongly typed, we would still need to define multiple Update structures even though their attribute set is identical, so that they can point to the correct Planning Resource object type.

2.      Some of our ObjectRefs can take one of a discrete set of Object types as their value (e.g. either a Planning Activity or a Planning Event)

I would suggest that this implies the ObjectRef should support polymorphism (e.g. be typed to an abstract or root class) and preferably a list of allowable types (as otherwise this may require an un-typed reference).

Cheers,

Roger

From: Sam Cooper [mailto:sam at brightascension.com] 
Sent: 08 July 2020 13:59
To: Stefan Gaertner; Churlaud Olivier; Cesar Coelho; Roger Thompson; Dan Smith; Radulescu, Costin (3900); Dominik Marszk; Coelho, César
Subject: MO Object requirements

Ok, so as mentioned in the last teleconference, we need to list the object features we want to support natively in the proposed MO COM rework.

>From what I have in my notes we are looking for:

*	Global object identifiers

*	These should be encoding agnostic, but by default are string based.

*	Inbuilt support for version identification
*	Support for strongly typed referencing of objects

My view is that MAL XML notation should have a first class, native, type for the above. This means that we don't just use String or Long but have an explicit type for each usage.

It has also been suggested that we look at simplifying the MAL message header, specifically resolving the ambiguities caused by having Domain in the header. One solution could be to move all object identification into the Object Identifier and only have messaging information in the message header (i.e. URI/URL).

Thoughts, suggestions, other?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-mp/attachments/20200804/7b7c9d74/attachment-0001.htm>