[Moims-mp] Discussion on MAL v2 Encoding

roger.rocketbrain at btinternet.com roger.rocketbrain at btinternet.com
Wed Mar 2 17:27:36 UTC 2022


Dear All,
 
In the MOv2 splinter session today the issue of encoding MAL Identifiers was
discussed.
See Césars word document considering encoding options and my presentation
summarising MPS usage of MAL Identifiers.
 
You will see in my presentation that MPS uses MAL Identifiers in the
following contexts:
 
1.	For the Area and Type fields of MO Object Identities (numeric values
already defined in our Blue Book)
2.	For the Key field of MO Object Identities of statically defined
objects (RequestDefinition, ActivityDefinition, EventDefinition, Resource,
PlanningUser)
3.	For the Key field of MO Object Identities of dynamically
instantiated objects (RequestInstance, ActivityInstance, EventInstance and
Plan).
4.	For the names of Arguments associated with RequestDefinitions,
ActivityDefinitions and EventDefinitions.
5.	For Function IDs
6.	For SubPlan IDs
7.	To reference external entities (User References for Requests, Source
Events, Activity Execution Instances and Plan Originators)
 
Consensus reached was as follows:
 
*	The encoding is handled at the transport binding layer, not at the
Application or MO Service (e.g. MPS Service) layers
*	To enable efficient encoding on-the-wire there is a dictionary that
maps MAL Identifiers (strings) to numeric values.  This does not know the
context of the Identifier, so it is simply a mapping of a particular text
string to a number.  This means, for example, if the same string is used as
an Identifier in an ActivityDefinition and an EventDefinition, there is only
one entry in the dictionary for that string – both will be mapped to the
same numeric value.  This greatly simplifies the structure of the dictionary
– which is scoped by Area, not Service, so there is one dictionary for MPS.
*	If there is no Dictionary or no entry in the Dictionary for a given
Identifier it will be encoded as a string.  Ground-to-ground XML exchange
can therefore be deployed without a Dictionary.  This also copes with
dynamically assigned Identifiers, at the cost of efficiency.
*	If a MAL Identifier corresponds to an integer value (however
represented within the implementation), then this can be encoded as an
Integer.  A flag in the encoded Identifier will indicate whether it is
encoded as a Dictionary look-up numeric value, a String or is an encoded
Integer value.  This allows for efficient encoding of dynamically created
MAL Identifiers, if they are numeric (integers).  Within the MPS book, we
should therefore add the recommendation that the Identity Key field for
dynamically instantiated MO Objects (PlanningRequests, Plans,
ActivityInstances and EventInstances) should be numeric to allow for
efficient encoding.  This makes sense, as dynamically creating a unique text
string would be more complicated than simply assigning the next available
number.
*	The Dictionary must be available to both Consumer and Provider – the
MAL will not define how the provision/synchronisation of these is achieved
(by out-of-bounds agreement).  It is anticipated that this will be supported
by the MO Common Service for Configuration.  The implication for MPS is that
where efficient encoding is required, a Dictionary should be provided that
maps all the IDs to numeric values for cases 1,2,4,5 and 6 above.  This
could be extended to cover Source Events and Plan Originators from 7.  For
case 3, numeric IDs are recommended.  For case 7, the default would be to
encode as strings.
 
The only impact on the MPS BB of this is to add the recommendation in bold
above.  It may also make sense to add a section clarifying what the MPS
Identifier dictionary would contain if it is needed.
 
I also raised the issue of restricting the character set available for MAL
Identifiers to allow for the proposed literal representation.  This met some
resistance, as it was seen as mixing up the encoding and presentation layers
– but the workaround suggested could imply the widespread use of escape
characters within expressions, making them pretty unreadable.  However, the
following was agreed:
 
*	A recommendation should be included in the MPS BB to restrict the
character set in MPS MAL Identifiers (excluding the special characters used
in the proposed ObjectRef literal format).  This can then apply to all MAL
Identifiers used within the MPS model itself, but not the Domain hierarchy
as this is wider than MPS.
*	It was agreed that the MAL itself will restrict the use of “.”
within the MAL Identifiers used for Domain.
 
Best regards,
 
Roger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-mp/attachments/20220302/005e7c22/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MPS use of MAL Identifiers.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 112389 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/moims-mp/attachments/20220302/005e7c22/attachment-0001.pptx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MAL_Identifiers_v0.3.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 81012 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/moims-mp/attachments/20220302/005e7c22/attachment-0001.docx>


More information about the MOIMS-MP mailing list