[Moims-mp] Updated Draft MPS BB and Model

roger.rocketbrain at btinternet.com roger.rocketbrain at btinternet.com
Wed Nov 30 12:17:45 UTC 2022


Dear All,
 
In preparation for this afternoon's WG telecon I have done some work on the
XML Service Specification export from the Book and can demonstrate this to
you.  It looks promising.
Currently it is loading data from the Data Structure and Service tables, but
not yet the Operation or Er
ror tables.  I have also not yet tackled the issue of loading in associated
text not contained in the tables into Documentation/Comment fields.
To me it highlights that the current table structures for Services are not
well-formed and could be better designed - but I assume that is not
something we wish to tackle.  For example, the "supported in Replay" tag is
not present in the tables.  We have comments relating to capability sets in
the non-normative tables in Section 2, but there is nothing in the standard
tables.
 
Working on this has brought a couple of other issues to light:
 
1.	One of the tables had the wrong name of the data structure in it
(cut and paste from the previous one) - it caused the macro to fail trying
to create two objects with the same name.  I have corrected in my master
version.
2.	Expressions:  we use derived types such as DurationExpression to
define fields - but in fact this is not allowed - you cannot derive from
concrete types, and although we have reserved SFPs for these typed
Expressions, they are all identical.  It also means that the type used in
the XML service specification is incorrect, as there is no such defined
type.  In practice it is a type restriction, not a derived type, and is
essentially the same concept as typed ObjectRefs, where we use the form
ObjectRef<ActivityDefinition>.  I therefore propose we use the same notation
as for ObjectRefs in the tables:  Expression<Duration>.  I would also change
the text after the definition of Expression to explain this, and remove the
reserved SFPs for the non-existent derived types.
3.	There is an enumeration defined in the Errors section, which was
included in the previous version of the XML Specification produced by CGI
Estonia - but it is not specified in a formal data structure table, so is
not picked up by the macro.  I suggest I change this to a standard table in
the document, so that it will be automatically picked up.
 
Cheers,
 
Roger
 
From: roger.rocketbrain at btinternet.com <roger.rocketbrain at btinternet.com> 
Sent: 08 November 2022 15:54
To: 'Peter.van.der.Plas at esa.int' <Peter.van.der.Plas at esa.int>;
'moims-mp at mailman.ccsds.org' <moims-mp at mailman.ccsds.org>
Subject: Updated Draft MPS BB and Model
 
Dear All,
 
I have made the edits resulting from the Fall Meeting and uploaded to the
Google Drive.
The new version of the MPS BB is Draft H and of the EA Model Draft W.
I have also regenerated the XSD schema.
I have also kept an Excel sheet detailing the points addressed, where the
updates are and the status of the update.  I've also uploaded this to the
Google Drive.
 
Please note that the number of edits made is quite significant, so I think
we need someone to read it through and make sure no inconsistencies or
errors have crept in.
 
There are a couple of open points to discuss at our next WG meeting, before
it is finalised for Agency Review:
 
1.	The new field "returnData" added to RequestInstance and
ActivityInstance as agreed (EnMap feedback point).  However, I did not add
this to the ActivityInstance structure in the XSD File Schema, as there is
no feedback file for Plans (other dynamic fields had been omitted
previously) - is this OK?
2.	New Planning Request state transition model.  I have not added any
new service operations.  Did we conclude that new service operations were
required to transition from the new "Processed" state to either Accepted or
Terminated?  The transitions are in the model - but not associated with an
operation.
3.	In the EA Information Model I have changed the representation of MO
Objects to fit with the revised SM&C inheritance approach (the identity
field is inherited).  However, I did not do this in the XSD File Schema - it
seemed an unnecessary abstract there to me (we only have Plan,
RequestInstance, ActivityInstance and EventInstance).  I renamed the
identity field for consistency, but kept it within the object classes.  Is
this OK?
4.	It would appear that SM&C have randomly decided to change the
representation of field names and types within the service operation tables.
I only found this out today, so have not changed it yet.  It will affect all
service operation tables if we wish to be consistent.
 
I made some minor structural changes to the document to facilitate the
automatic generation of the service specification XML.  This includes
setting the Alt-Text Title field (not visible in the on-screen or printed
document) so that macros can identify which table defines what.  I may need
to make a few more minor layout adjustments to facilitate the capture of
"comments" from the document text.
 
I have done some preliminary work on an add-in template with macros to
export the service specification XML.  The approach I have taken is to
create a Word VBA class model representing the data structures, services and
service operations.  The classes will then have methods to import the
corresponding information from the tables in the book, and to write it out
as an XML fragment.  A macro will then load the class model from the book;
and write the XML specification out from the model (calling the class
methods).  I've been concentrating on data structures so far - will not have
much to show for the WG telecon.
 
Assuming this works (don't see why it shouldn't) - we might want to consider
the reverse process in due course, perhaps only for the tables themselves.
In this way the tables in the book could be updated from the XML
specification.
 
Please note I shall be on leave from 15th November for 10 days.
 
Best regards,
 
Roger
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-mp/attachments/20221130/b9224669/attachment-0001.htm>


More information about the MOIMS-MP mailing list