[Moims-mp] References to other Activities in the context of ActivityDetails

[roger.rocketbrain at btinternet.com]

Hi Peter and Quinten,
 
I just wanted to put my thoughts down on an open issue which was raised
during our discussions on Wednesday.
 
The issue is that the most useful references to other Activities contained
in ActivityDetails structures (for example in Constraints) are to other
Activities also defined as ActivityDetails structures contained within the
same overall MO Object - either an ActivityDefinition or a PlanningRequest.
This is what allows users to specify a template for a sub-schedule of
activities to be incorporated in a plan.  This can be either a pre-defined
hierarchical structure (an ActivityDefinition) or a user initiated
PlanningRequest.
 
It should be possible to specify constraints (typically temporal/sequential)
between  the child activities defined in these cases.  Currently this is not
possible, as there is only an ObjectRef, and the ActivityInstances
associated with the ActivityDetails have not yet been instantiated by the
planning system (that is what the ActivityDetails is specifying).  It would
be very cumbersome to have to define these constraints in a second pass
after the instances have been created.  It is also highly desirable that
such tightly coupled information be defined once in a single place.
 
A few simple example use cases relating to either an ActivityDefinition or a
PlanningRequest (the "parent" object):
 
1.	In the parent object,  ActivityDetails are specified for two child
activities (A and B) and a constraint is applied to B that says it should
sequentially follow A.  This requires a reference to its sibling
ActivityInstance that has not yet been created.
2.	The parent object has a child activity (A) and an argument of type
ObjectRef (X) that is used to point to an EventInstance.  A constraint is
applied to A that it should sequentially follow X.  This requires a
reference to an ObjectRef contained in an Argument of the Parent.
3.	The value specified for an Argument of the child activity (A) is
taken from an argument of the same type of the parent object (Y).  This
allows an argument of any type to cascade down to child activities.
 
Previously this was supported as an Expression of type ObjectRef and a
rather convoluted default literal ObjectRef syntax that allowed for
references to Arguments and to the children of the parent.  Now only an
ObjectRef itself is supported - and from Wednesday's discussions this should
be extended to allow references to ActivityDefinitions and EventDefinitions
as well as ActivityInstances and EventInstances.  However, this does not
support the two use cases above.  It is my view that these represent an
essential capability of the standard.
 
To reference a sibling activity, a reference to the class ActivityDefinition
could be used, but this has drawbacks:
1.	What if there is more than one sibling of the same class?
2.	Is such a reference constrained to be an Activity of that class
contained in the same parent, or can it also refer to all ActivityInstances
of that class?  We probably want both cases.
 
There is no current way to reference an ObjectRef contained in an Argument.
 
My suggestion is that these ObjectRef attributes contained in Constraints
should be changed to a new MPS type - lets call it IndirectRef (I'm sure you
can come up with a better term).  This essentially works as a primitive
expression of type ObjectRef
IndirectRef is an Abstract type, with three subtypes:
1.	DirectRef - which simply contains an ObjectRef as now.  A reference
can be made to an extant Activity or EventInstance, or to the class Activity
or EventDefinition.  If a Definition is referenced then the constraint is
with ALL instances of that class.
2.	ArgumentRef - in which the name of an Argument of the parent of type
ObjectRef can be specified.  The referenced object (ActivityInstance or
EventInstance) then resolves at run-time to that passed in as an Argument to
the parent Object.
3.	SiblingRef - in which the sequential number of the ActivityDetails
contained in the children of the parent object is specified.  The referenced
object then resolves at run-time to the instantiated sibling
ActivityInstance.  A variant of this would be to add a Name field to the
ActivityDetails so that the ActivityDetails can be referenced by Identifier
rather than Index.
 
This doesn't cater for the case of assigning values to child arguments based
on the parent arguments, but a similar approach could be taken with a new
abstract type IndirectVal, with two sub-types DirectVal (a value) and
ArgumentVal, which specifies the name of an Argument of the parent.
 
Finally, it occurs to me that this can be wrapped up together with your new
approach for Expressions.  As I recall you have an Abstract type with two
sub-types:
1.	That contains a MAL::Element
2.	That contains an Expression (Type, Language, Expression)
 
Simply extend this to include two additional sub-types:
3.	ArgumentRef that contains the name of an argument of the Parent
object that should be assigned as the value of the expression at run-time.
4.	SiblingRef - which contains a reference to the Index or Identifier
of the child Details object (could be ActivityDetails, EventDetails or other
similar data class).  This resolves to an ObjectRef to the corresponding
object instantiated at run-time.
 
Hope my ramblings are of some use!
 
Best regards,
 
Roger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-mp/attachments/20241108/3ab43b6b/attachment-0001.htm>