[Moims-sc] Draft MPDS Blue Book and XML Specification for WG review

[roger.rocketbrain at btinternet.com]

Hi Olivier,
 
Responses below.  Sorry to be negative on some issues – but I really think we need to concentrate on getting the book out for agency review, rather than making cosmetic changes.
 
Cheers,
 
Roger
 
From: MOIMS-SC <moims-sc-bounces at mailman.ccsds.org> On Behalf Of Churlaud Olivier via MOIMS-SC
Sent: Wednesday, February 28, 2024 2:07 PM
To: moims-sc at mailman.ccsds.org
Subject: Re: [Moims-sc] Draft MPDS Blue Book and XML Specification for WG review
Sensitivity: Confidential
 
Dear all,
 
First of all, sorry for having missed yesterday's meeting. It seems I had an email issue : the meeting was not in my agenda until today....
 
I have some minor comments on the book itself (see below), and comments on other people comments (like renaming of some Composites or authorization of NULLs in some interfaces).  How do we deal with the discussion on other people comments?
 
My comments on the book are the following:
1.	The area should be MPD and not MDPS (because we never put the "Service" part in the name: otherwise MAL would be MALS, MC would be MCS, MPS would be MPSS etc...)
[RST] OK 
2.	The tables of composites/messages are not the same as what was defined in MAL : we should really be consistent between books.
[RST] I have said previously, the differences are cosmetic – but the autogeneration macro that produces the XML Specification from the book currently works on this format of table and it is really not worth the effort to rework the macros and then having two versions of it to maintain (one for MPS with which it is consistent, other than colour, and one for MPD).  I also happen to think the MPD style is more compact and less wasteful of space than the historic MAL version.
3.	In M&C we decided to often use key + domain instead of an objectRef as it is more understandable by humains (and lighter on bandwith). Wouldn’t it be relevant in MPDS as well ?
[RST] This doesn’t work if you are going to reference objects outside the Area.  There is at least one case of this in MPDS.
4.	In the operations GetProduct / GetProductFile
a.	it's actually a getProduct(File)s (plural)
[RST]  OK
b.	I wonder if the ack could return the number of elements to retrieve if known, 0 if not
[RST] ACK can’t return any data.  The RESPONSE message could return the number of products/files delivered – but as there is an update message per Product it seems unnecessary to me.
5.	The service "Product Delivery" and its operations are named from the point of view of the provider, whereas all other services are named from the point of view of the subscriber. To be consistant I would rename notifyProductDelivery => monitorProductDelivery and deliverProducts => receiveProduct (or a better verb?)
[RST] Many Delivery services come to my house – I don’t think it is named from the point of view of the provider and it is also in the name of the Book.  Would be another cosmetic change with no benefit.
 
Thank you 
Olivier
 
 
-----Message d'origine-----
De : MOIMS-SC <moims-sc-bounces at mailman.ccsds.org <mailto:moims-sc-bounces at mailman.ccsds.org> > De la part de Serge Lacourte via MOIMS-SC
Envoyé : mardi 27 février 2024 18:07
À : moims-sc at mailman.ccsds.org <mailto:moims-sc at mailman.ccsds.org> 
Objet : Re: [Moims-sc] Draft MPDS Blue Book and XML Specification for WG review
 
Hi All,
 
here are my comments on the MPDS book.
 
Best regards,
 
-- 
Serge Lacourte
Directeur general
ScalAgent Distributed Technologies SA
tel. +33 4 76 29 79 81
mobile. +33 6 86 47 41 06
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-sc/attachments/20240228/4fb9fe78/attachment-0001.htm>