[Moims-mp] Updated MPS Blue Book, EA Model and XSD Schema

[roger.rocketbrain at btinternet.com]

Dear Peter and All,
 
I have uploaded my latest version of the MPS EA Model (Draft U) and MPS Blue
Book (Draft G) to the Google Drive together with an updated set of XSD Files
generated for the File Schema.
 
This should have addressed all outstanding comments from the WG and the
outcome of discussions on the draft MAL BB, except where detailed below.
 
I also reviewed the new MAL rules on polymorphism - which largely removes
the restrictions we had previously, but does forbid extension of concrete
(non-abstract) classes of which we had several cases.  I have now remodelled
our data structures to remove any inheritance from concrete structures.  The
main cases of this were in Resource sub-types (now gone).  The Position and
Direction types have also been remodelled.
 
As agreed in our last Telecon, I have created an Appendix with a proposed
literal representation for ObjectRef, Position and Direction types and
expressions.
 
Outstanding issues:
 
1.	The MAL BB discussions highlighted that the
monitorPlanExecutionDetail operation as currently formulated with three
distinct update messages is not valid.  We need to decide how to
reformulate.  The SM&C WG gave 3 options: a) The operation is split into 3
separate PubSub subscriptions;  b) A supertype is defined to allow the three
different Update structures to be supported through polymorphism;  c) a
structure is defined with 3 optional fields corresponding to the 3 types of
update - at least one of which must be populated.  Option a) is not ideal
for MPS, b) is preferred if possible given polymorphism constraints (cannot
have two abstract parents), c) will be adopted as a fall-back solution.
2.	Following discussion with Peter, I have remodelled Position and
Direction classes to have a single abstract class for each, with subclasses
that contain the required set of attributes for each coordinate type
representation.  In performing this rationalisation (which simplifies the
structure) a new sub-class of Position (OrbitalPosition) has been created
that is consistent with the OrbitalTrigger and Repetition classes.
Similarly a SurfacePosition class has been created to represent positions on
the surface of a planetary body using longitude and latitude representation
that is symmetrical with the SphericalDirection type.  These should be
reviewed by the group, but also the possibility of rationalising Trigger and
Repetition subtypes by taking these new classes into consideration should be
considered:
a.	The creation of the OrbitalPosition as a type of Position means that
the subclassing of LocationConstraint and LocationTrigger to allow separate
concrete subclasses for PositionConstraint / OrbitalPositionConstraint and
PositionTrigger / OrbitalPositionTrigger becomes unnecessary as the Orbital
specialisation can be represented by the general case if the position type
is OrbitalPosition.  The same does not apply to OrbitRepetition as the
repetition pattern differs.
b.	If we were to create an additional Direction type to represent
Revolution, we could make the same rationalisation for PointingTrigger and
PointingRepetition.  This may not apply to RevolutionConstraint.
3.	WG to review my proposed approach to literal representation for
ObjectRef, Position and Direction types.  If agreed, we may wish to forward
our thinking on ObjectRef to the SM&C WG - as this is common to all MO
standards based on the MAL, and it implies restriction on the characters
that can be included in a MAL Identifier.
4.	We should discuss the approach taken on defining the Time and
Coordinate system Enums.  We have defined these in the information model and
file structure XSDs as Enums - but the set of options is outsourced to SANA
registry items maintained by the NAV WG (or not in the case of Coordinates).
We should review whether the attribute should be a string - which can then
take any value, but should be constrained to be those in the SANA
registries.
5.	For the XSD generation, Peter has been working on a macro to
post-process the autogenerated XSDs to replace the List definitions with a
more formal structure.  This would have no impact on the EA Model or the BB.
I have added "pattern" tags to the File Structure model XSD types for MAL
Identifier, Time and FineTime types.  However, these do not get carried
through to the XSDs as restrictions.  They may also need to be added to the
MALTypes XSD manually.
 
Cheers,
 
Roger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-mp/attachments/20220210/546c7ef0/attachment-0001.htm>