[Moims-mp] MPS Model Updates

[roger.rocketbrain at btinternet.com]

Dear All,
 
I have reviewed the draft new MAL Blue Book and am working through Maria and
Peter's comments on the existing MPS Blue Book and models.
 
Some points to note on the MAL Blue Book:
 
1.	I have noted points for clarification that could require update to
the MPS Blue Book and models (but not in a major way):
a.	I have currently assumed a single MAL Attribute type for ObjectRef;
the draft MAL BB identifies two separate MAL Attribute types for ObjectRef
and ObjectRef<T>.  If that is upheld, I will need to make the corresponding
changes in our Information Model, Blue Book and File Schemas - but it is not
a major piece of work to do this.
b.	I have currently assumed that Domain (in ObjectIDs and PubSub
Subscriptions) is an Ordered List of MAL Identifiers;  the MAL BB identifies
it as a single MAL Identifier, which implies any hierarchical structure is
encoded within that Identifier (e.g. using dot notation).  This would
require a few small changes to our models and the book.
c.	In the draft MAL book, wildcards are only permitted on the last
element of a Domain hierarchy (see above).  My view is it should be allowed
anywhere in the hierarchy - but the impact on the MPS BB would only be to
clarify this in the text.  It would, however, mean you could not subscribe
to the same subsystem for multiple spacecraft in a constellation, e.g.
Galileo.*.AOCS
2.	The rules for polymorphism are clarified in the draft MAL BB - and
are consistent with previous agreement.  However, this does mean you cannot
have a Concrete Type derived from another Concrete Type.  Concrete Types
must be derived from Abstract Types.  We do have cases of this, and they
will need to be changed in our model and BB.  Note you can now have an
Abstract Type as a field in a MAL message (we were relying on this!).  I
have reviewed the MPS BB and models and found the following four cases of
extended Concrete Types in our model:
a.	The Resource Object has 3 derived sub-types:  Numeric Resource,
String Resource and Status Resource, but Resource is itself concrete.  I
think we discussed this in the past, but no changes have yet been made.  The
derived Resource types are to allow type-specific validation details.  Given
that we can now have an abstract type as a field, I propose the following
solution:
                                                               i.      There
is only one MO Object type for Resource
                                                             ii.      A
field is added to the Resource object "validationData" of type
"ValidationDetails".  
                                                           iii.      The
field can be null.  
                                                           iv.
ValidationDetails is defined as a new abstract type, with three concrete
subtypes corresponding to validation details for Numeric, String and Status
types respectively.
b.	The same situation arises for Argument Definitions, with three
derived subtypes.  The validation details are identical to those for
Resources, except that the Numeric type includes a precision field.  I
propose the following solution:
                                                               i.      Adopt
the same approach as for Resource, with only one concrete type for ArgDef
                                                             ii.      Reuse
the same ValidationDetails types - include their definition in MPS
Additional Data Types to be common to both Resources and Arguments
                                                           iii.      Add a
precision field to the Numeric validation details for Resources as well as
Arguments.
c.	ComplexResourceConstraint is derived from ResourceConstraint (which
is concrete).  Maria had already highlighted a related issue with the naming
and type of the value field.  Proposed solution:
                                                               i.      Make
ResourceConstraint abstract and remove the value field from this.
                                                             ii.      Add
SimpleResourceConstraint derived from the above and add the value field to
this.
                                                           iii.      Rename
the value field of ComplexResourceConstraint to valueProfile.
d.	Derived Expression types.  These do not contain any additional
attributes, but are effectively a shorthand means of expressing a constraint
on the type of expression supported in a particular context.  Either we do
not consider these to be real concrete types (only the Expression type is
concrete) - or we should make Expression abstract.
 
Note that changes to the set of concrete types will have impact on the Short
Form Parts assigned throughout the BB.
 
I would appreciate your feedback/agreement on my proposed approach for 2)
above before I proceed to make the changes.
 
Cheers,
 
Roger
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-mp/attachments/20220126/7164432e/attachment-0001.htm>