[Moims-mp] Updated MPS Blue Book draft and Model

[roger.rocketbrain at btinternet.com]

Dear All,
 
I have uploaded the latest draft (F) of the MPS Blue Book to the google
drive at
https://docs.google.com/document/d/1cJufrdAG_CbsPkFhe9snXagsvGOXsJ9K/edit?us
p=sharing
<https://docs.google.com/document/d/1cJufrdAG_CbsPkFhe9snXagsvGOXsJ9K/edit?u
sp=sharing&ouid=106200809466753231515&rtpof=true&sd=true>
&ouid=106200809466753231515&rtpof=true&sd=true
And also the associated EA model (draft S) at
https://drive.google.com/file/d/1iyhyZJtw8G3qXXrgj9wTvS5mCnQ5XIya/view?usp=s
haring
 
A number of updates have been made in the documents and model:
 
1.	To reflect the agreed position on comments received during the Fall
meeting (mostly from Peter)
2.	To reflect the current agreed position regarding MO v2 changes by
the SM&C working group, including:
a.	Approach to support of PubSub subscriptions (domain treated as a
special case; other subscription keys can have multiple values)
b.	Approach to ObjectRef MAL::Attribute type - has been a bit of a
moving target - but I have hopefully consolidated on the current position
which is that:
                                                               i.      There
is only one ObjectRef MAL::Attribute type, but this can be specified as
ObjectRef or ObjectRef<T>.  ObjectRef<T> is a reference to the nominated
concrete MO Object Type T.  If specified, the referenced type is implicit
and the encoded reference may omit the area and type of the Object.  If the
type not specified, then the reference is explicit and may be to any MO
Object type, the encoding including the area and type.
                                                             ii.      MPS
ObjectRefs are mostly of the implicit variety with a single specified
concrete object type - this has required extensive editing to include the
type in each field definition.
                                                           iii.      MPS has
no ObjectRefs that are truly unconstrained by object type.  We have cases of
references that can be to more than one type, eg: <ActivityInstance |
EventInstance>;  and cases where a reference can be to any sub-class of a
nominated abstract class, eg. <Resource>.  I lost the argument that these
restrictions should be part of the formal specification syntax. I have
therefore defined within the description field in the data structure tables.
c.	Note that some updates have been required to general sections of the
document to be in line with this; and several information model diagrams
needed to be updated for consistency.
2.	To complete as far as possible the text of Section 7 on XML File
Formats.  This has been updated to:
a.	reflect discussions during the Fall meeting, and to include the
MPSPlanningResponseFile format.
b.	Adopt a more logical structure
c.	Add requirements - which are exclusively on encoding, at least at
present.
3.	Within the EA model:
a.	Made changes consistent with agreements from the fall meeting
b.	Completed the XSD File Structure model by adding:
                                                               i.
PlanningRequest and PlanningResponse files
                                                             ii.
Completing Triggers and Constraints
                                                           iii.      Adding
Position/Direction Types and Repetitions
 
Known outstanding issues:
1.	Attribute order in the generated File Structure xsd files is not
preserved.  I have raised the issue with Sparx Systems, who have responded
with a work-around, but do not intend to correct the current behaviour.  The
work around requires me to enter position tags for all attributes in the XSD
File Structure model.  I have yet to do this.
2.	Finalisation of the position of the NAV WG on coordinate reference
schemes and the associated SANA registry,
 
See you all at our WG meeting on 1st December.
 
Best regards,
 
Roger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-mp/attachments/20211129/a3143940/attachment-0001.htm>