[Moims-mp] MALv2 Updates, MPS BB and XML Specification

roger.rocketbrain at btinternet.com roger.rocketbrain at btinternet.com
Fri Mar 10 16:30:10 UTC 2023


Dear All,
 
I participated in the SM&C WG Telecon on Tuesday and a splinter session on
MAL issues yesterday.  I thought I would give the MPS WG a quick update on
the impact on the MPS Blue Book of proposed changes.
Two issues were discussed which had potential impact on MPS:
 
1.	Errors:  MAL defines common errors applicable to all MO Services,
and these are numbered starting at 64k.  Previously we had specified MPS
specific errors starting at 80000.  There was some ambiguity in the MAL book
on the way Error numbers should be assigned, but apparently Error numbers
assigned at Service level should have numbers starting at 0.  However, these
did not work with the current test bed, which was why we had started our
numbering at 80000.  It has now been clarified that Errors above 64k are
reserved for common errors defined at MAL level, and that other Errors
should be defined at Area level (which MPS was already doing), but that
these should start at 0.  This means that the same Error numbers may be used
for different errors in different Areas.  I will need to update the MPS
book, to bring the MPS error numbers into line, starting numbering at 0..
I also asked about the representation of Errors within the XML.  For MPS we
have a single table at Area level, which defines the Error numbers, their
names, a comment, and the definition of the ExtraInfo for that Error.
Currently, in the XML, the definition of the XML at Area level includes only
the number, name and comment:  ExtraInfo is defined at service operation
level, where an Error Reference is made for applicable errors.  I questioned
whether it would be more logical for the ExtraInfo to be defined once at
Area level, rather than multiple times in each occurrence of its use at
service operation level.  Although the rationale for this was understood, it
was pointed out that for MAL errors, a Service operation could specify
custom ExtraInfo usage, so it was decided to stick with the current
representation.
2.	Polymorphism and approaches to encoding of abstract types in both
List<TypeA> and ObjectRef<TypeA>:  there had been an email exchange on this
topic as a result of questions arising during prototyping.  A suggested
resolution to the issue raised was for Short Form Parts (SFP numbers) to be
assigned to Abstract Types (currently only concrete types have SFPs).
Following an extended discussion, it was concluded that it was not necessary
to assign SFPs to abstract types.  No change is therefore required to the
MPS BB.
 
For the MPS BB, therefore, the only update required is to renumber the
Errors.
 
As regards the export of the XML Specification from the MPS BB, there are
three outstanding issues:
 
1.	Error references remain for individual service operations remain to
be included.  Following the discussion on point 1 above, it was confirmed
that these references must include the definition of the ExtraInfo field.
2.	Mal Documentation sections have been included at Service level for
High-Level and Functional requirements.  In MPS we do have Structural
requirements sections at Service Operation level.  Having reviewed these,
their only purpose is to define the subscription keys for PubSub operations
- this is now formally included in the Operation specification tables and
represented in the XML specification using the Message construct at service
operation level.  I propose, therefore to omit these Structure requirements
sections from the XML specification, as they are already represented in the
XML (and MAL documentation sections are currently only defined at Service
level).
3.	Comments are not currently attached to Data Structures in the
exported XML specification.  I propose to include any text preceding the
Data Structure Table in the BB as the comment.
 
Best regards,
 
Roger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-mp/attachments/20230310/3998fb01/attachment-0001.htm>


More information about the MOIMS-MP mailing list