[Moims-dai] RE: Edits to Corot test case

Boucon Daniele Daniele.Boucon at cnes.fr
Mon Feb 23 16:39:13 UTC 2015

Hi all,

Thank you Mike and Don for your reactivity!

Please find enclosed my contribution, added to Don's last document (word document with revision marks, PDF without marks):
* remaining TOPICs filled in,
* tables, examples and annex updated with the correct IDs.
*still to be done: figure-1 to be updated, and have asked Stephane for the original figure.

I'm ok with Don and Mike's proposals (also with the replacement of all the benefits by one sentence).

I'm ok with the algorithm, except that the CNES proto doesn't check the size of the TO against the max size specified in the MOT (not implemented, should be implemented in an operational tool). 
As a remark: TO to be deleted or replaced could also modify the number of archived objects (this is implemented).
Include a diagram is a good idea, but personnaly I have no time to build such one now.

Could you please remind me what has been decided for paragraph 2?

If no other comments by Wednesday, I'll include Mike's part in the document and will send the document to the manager of Corot project for review end of this week.



-----Message d'origine-----
De : Mike Martin [mailto:tahoe_mike at sbcglobal.net] 
Envoyé : samedi 21 février 2015 16:20
À : Donald Sawyer
Cc : Boucon Daniele; Stéphane Mbaye; John Garrett; MOIMS DAI List
Objet : Edits to Corot test case

Hi everyone

My action items on Corot test case.

Thanks, Mike

1.  6.4.1  benefits

I can't understand the significance of the specific (to this use case) benefits in the bullets so would suggest that we delete them and just extend the introductory sentence a bit.

"This use case provides an example of PAIS configurations for bulk transfers and highlights the control of sequencing as the housekeeping data must be transferred before the science data."

2.  Text version of SIP Ingestion process description.  I would remove the line by line description.  It would be nice to include a diagram showing the steps, but I don't imagine we have the resources to do that.

"The software must first read the project Descriptors and SIP Constraints and extract and store identifiers and constraint values. 
The zip file containing the SIP is unpacked into working storage. The XFDU manifest is opened and read.  The project ID, SIP Type ID and Sip sequence number are checked against the descriptors.  The software will cycle through the manifest checking for Transfer Objects, Group Types, Data Object Types and Files.  These are stored within XFDU Content Units.  For each Transfer Object Type: check that Transfer Object Type ID is allowed for the current SIP Type; that the last Transfer Object of this type has not already been ingested; that the maximum occurrence with respect to a project global counter for each Transfer Object type has not been exceeded; and update the project global counter for the Transfer Object type.  For each Group Type: check the maximum occurrence of this Group in the parent Group or Transfer Object type.  For each Data Object Type: check the maximum occurrence of this Data Object in the parent Group.  For each Data Object File check the maximum occurrence of this Data Object File in the current Data Object; check the Data Object file presence according to the URL; verify the file size; compute/update and check maximum size of this Transfer Object; verify the file checksum; verify that this file was not already ingested and compute internal file path according to the name preservation rule of the current Transfer Object type; copy or move the file to the internal file path and register the file as ingested.  This is the bottom of the object hierarchy.  As the software moves back up the object hierarchy (Data Object, Group and Transfer Object) the minimum 
occurrence at each level is checked.   Back at the Transfer Object Type 
level the minimum size is checked and a counter incremented for this Transfer Object Type.  If the last Transfer Object flag is set, check that the counter for this Transfer Object type is below the minimum occurrence and record that the last Transfer Object of the type has been received.  Continue to cycle through Transfer Objects Types to the end of the manifest."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 651x2g0-[6.4]-corot-20150202DMS2DB2.pdf
Type: application/pdf
Size: 720373 bytes
Desc: 651x2g0-[6.4]-corot-20150202DMS2DB2.pdf
URL: <http://mailman.ccsds.org/pipermail/moims-dai/attachments/20150223/f83f00e4/attachment.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 651x2g0-[6.4]-corot-20150202DMS2DB2.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 410244 bytes
Desc: 651x2g0-[6.4]-corot-20150202DMS2DB2.docx
URL: <http://mailman.ccsds.org/pipermail/moims-dai/attachments/20150223/f83f00e4/attachment.docx>

More information about the MOIMS-DAI mailing list