<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1426614265;
mso-list-type:hybrid;
mso-list-template-ids:-25541836 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:.25in;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:.75in;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:1.25in;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:1.75in;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:2.25in;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:2.75in;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:3.25in;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:3.75in;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:4.25in;
text-indent:-.25in;
font-family:Wingdings;}
@list l1
{mso-list-id:2052262937;
mso-list-template-ids:2019200840;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2
{mso-list-id:2126918943;
mso-list-type:hybrid;
mso-list-template-ids:1775372838 67698699 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l2:level1
{mso-level-number-format:bullet;
mso-level-text:\F0D8;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:.25in;
text-indent:-.25in;
font-family:Wingdings;}
@list l2:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:.75in;
text-indent:-.25in;
font-family:"Courier New";}
@list l2:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:1.25in;
text-indent:-.25in;
font-family:Wingdings;}
@list l2:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:1.75in;
text-indent:-.25in;
font-family:Symbol;}
@list l2:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:2.25in;
text-indent:-.25in;
font-family:"Courier New";}
@list l2:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:2.75in;
text-indent:-.25in;
font-family:Wingdings;}
@list l2:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:3.25in;
text-indent:-.25in;
font-family:Symbol;}
@list l2:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:3.75in;
text-indent:-.25in;
font-family:"Courier New";}
@list l2:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:4.25in;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#0563C1" vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal><span style='color:#1F497D'>I’ve been having side discussions with other folks on document colors, so I thought I’d expand my first paragraph immediately below with CCSDS background, as I understand it. <o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#993366'>People all over CCSDS have problems with book colors, so we’re not alone. But it seems fairly simple to me. <o:p></o:p></span></p><p class=MsoNormal><span style='color:#993366'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#993366'>The first principle is that we don’t mix requirements types. The three types are:<o:p></o:p></span></p><ul style='margin-top:0in' type=disc><li class=MsoListParagraph style='color:#993366;margin-left:-.25in;mso-list:l2 level1 lfo4'>Informative (not normative) (which is then designated as green)<o:p></o:p></li><li class=MsoListParagraph style='color:#993366;margin-left:-.25in;mso-list:l2 level1 lfo4'>Normative but not testable specifications (which is then designated as magenta)<o:p></o:p></li><li class=MsoListParagraph style='color:#993366;margin-left:-.25in;mso-list:l2 level1 lfo4'>Normative and testable (which is then designated as blue)<o:p></o:p></li></ul><p class=MsoNormal><span style='color:#993366'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#993366'>The CCSDS “founding fathers” seemed to think that it was really important for a project manager to know which documents he can slap on a contract and use with no further effort on his part (blue) and which documents will require additional systems engineering effort by his project (magenta). And which documents are simply rationale (green) to justify/explain the blue and magenta specs. So their rules are to carefully separate these types of requirements/statements into separate documents. (In reality, the “options” factor will require some systems engineering for all standards adoption, but not as much for blue as for others.) The “founding fathers” believed that rigorous blue books are the primary reason for the success of CCSDS to date. <o:p></o:p></span></p><p class=MsoNormal><span style='color:#993366'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#993366'>Working groups should *<b>not</b>* first write a book and then try to figure out what color it is. In that case, they will end up with mixed colors in one book, and then everyone kills time (and sews discontent) arguing about what color it should be. Working groups should decide on a document tree and provide pigeonholes where they can stuff informative, normative-non-testable and normative-testable statements. <o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>That’s it. That’s why I proposed a document tree. Hope that background helps. <o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><div><p class=MsoNormal><span style='color:#002060'> -=- Mike<o:p></o:p></span></p><p class=MsoNormal><span style='color:#002060'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Mike Kearney</span><span style='color:#002060'><o:p></o:p></span></p><p class=MsoNormal><span style='color:#002060'>Huntsville, Alabama, USA <o:p></o:p></span></p></div><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> kearneysolutions@gmail.com <kearneysolutions@gmail.com> <br><b>Sent:</b> Wednesday, December 16, 2020 10:41 AM<br><b>To:</b> 'MOIMS-Data Archive Interoperability' <moims-dai@mailman.ccsds.org><br><b>Subject:</b> RE: [Moims-dai] OAIS-IF Document Tree<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Roger that on the magenta book. That’s how I painted it in the document tree. However, I think it’s more important to decide whether we’re going to have a normative/testable/implementable document or not, and then decide whether it’s green, magenta or blue. We decide what we need, and that determines the color. I think Steve is still figuring that out. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>By the interfaces on the bottom, I think you mean to move the bindings/adapters under the AAL, right? I considered that, but traditionally an architecture “umbrella” type document specifies the interaction between components, like interactions between the user interfaces and the abstraction layer, and the interactions between the abstraction layer and the bindings. Hence it constrains both AAL and bindings/adapters equally, so both AAL and bindings/adapters “report to” the Architecture document. Or their interfaces (UserIF<span style='font-family:Wingdings'>ßà</span>AAL, and AAL<span style='font-family:Wingdings'>ßà</span>bindings/adapters) are specified by the Architecture document. However, if you really think the interfaces between the AAL and the bindings/adapters, as well as the functioning of the bindings/adapters will all be specified in the AAL, we can move them under the AAL. But I would think the user interfaces (PAIS/PAIP/CAIS/CAIP) would equally be specified by the AAL, so then we’re moving everything under the AAL. That doesn’t seem like a good document tree to me. It doesn’t look like a functional decomposition process, as a normal project would see. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>However, we can talk about it more. If the consensus is that everything should be moved under the AAL, we can do that. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><span style='color:#002060'> -=- Mike<o:p></o:p></span></p><p class=MsoNormal><span style='color:#002060'><o:p> </o:p></span></p><p class=MsoNormal>Mike Kearney<span style='color:#002060'><o:p></o:p></span></p><p class=MsoNormal><span style='color:#002060'>Huntsville, Alabama, USA <o:p></o:p></span></p></div><p class=MsoNormal><o:p> </o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> MOIMS-DAI <<a href="mailto:moims-dai-bounces@mailman.ccsds.org">moims-dai-bounces@mailman.ccsds.org</a>> <b>On Behalf Of </b><a href="mailto:garrett@his.com">garrett@his.com</a><br><b>Sent:</b> Wednesday, December 16, 2020 12:59 AM<br><b>To:</b> 'MOIMS-Data Archive Interoperability' <<a href="mailto:moims-dai@mailman.ccsds.org">moims-dai@mailman.ccsds.org</a>><br><b>Subject:</b> Re: [Moims-dai] OAIS-IF Document Tree<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Hi Mike,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks.<o:p></o:p></p><p class=MsoNormal><br>Before I start, I will mention that our CCSDS Project is currently expected to generate a Magenta architecture book.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I think your first slide is pretty good, except I would put most of the interfaces on the bottom, right side items should appear under the Archive Abstract Layer. I also think there will be some direct implementations of AAL for example a Java or Python implementation. Thinking about it, there could also be some database implementation works also.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>May there be peace in your life,<o:p></o:p></p><p class=MsoNormal>-JOhn <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> MOIMS-DAI <<a href="mailto:moims-dai-bounces@mailman.ccsds.org">moims-dai-bounces@mailman.ccsds.org</a>> <b>On Behalf Of </b><a href="mailto:kearneysolutions@gmail.com">kearneysolutions@gmail.com</a><br><b>Sent:</b> Tuesday, December 15, 2020 5:23 PM<br><b>To:</b> 'MOIMS-Data Archive Interoperability' <<a href="mailto:moims-dai@mailman.ccsds.org">moims-dai@mailman.ccsds.org</a>><br><b>Subject:</b> [Moims-dai] OAIS-IF Document Tree<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Today’s telecon had a soul-searching discussion of what an ADD (Architecture Description Document) is, and what the Blue book that we’re currently developing is. Steve described it’s tendency towards focusing on the details of the Archive Abstraction Layer, and hence we began to discuss whether the content currently in the blue book is really ADD material or AAL Blue Book material. This led to a discussion where I said we should have a document tree, so naturally I got the action to build it. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Attached is a PPT with a first notional cut at a document tree. I’ll also suggest that a Doc Tree figure should actually be in the ADD, or even perhaps the OAIS Reference Model document (next revision, of course). This ADD after all, is intended to be the ADD for the OAIS-IF, not an overall OAIS architecture. The OAIS-IF ADD is subordinate to the OAIS RM, not the other way around. I did not try to include the shadow-organization of an ISO Doc Tree. To be complete we should probably do that, and spell out acronyms. Right now I consider this a working document for us insiders. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>A few comments are in the notes of the PPT charts. Two additional charts from IPELTU and our CMC material are added for reference. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Some background on ADDs: There is only one other in CCSDS, for Cross Support, the CCSS-ADD, and it is here:<o:p></o:p></p><p class=MsoNormal><a href="https://public.ccsds.org/Pubs/901x0g1.pdf">https://public.ccsds.org/Pubs/901x0g1.pdf</a><o:p></o:p></p><p class=MsoNormal>It is a green (informative, not normative) book, and it has a companion Magenta book (an ARD – Architecture Requirements Document). The ARD is not in our plan. We could conceivably have a magenta ADD that includes normative requirements like an ARD. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Some notable statements from the CCSS-ADD (relating them to our OAIS-IF ADD): <o:p></o:p></p><ul style='margin-top:0in' type=disc><li class=MsoListParagraph style='margin-left:-.25in;mso-list:l0 level1 lfo3'>The foreword on page ii says: The architecture described in this document was developed based on the Cross Support Reference Model…” Our counterpart statement is that our ADD is based on the OAIS Reference Model. <o:p></o:p></li><li class=MsoListParagraph style='margin-left:-.25in;mso-list:l0 level1 lfo3'>Section 2.1, page 2-1: “The SCCS communications architecture reference model described in this document establishes a common framework that provides a basis for developing, providing, and using space communications cross support services.” Our ADD does the same for Archive Services. <o:p></o:p></li><li class=MsoListParagraph style='margin-left:-.25in;mso-list:l0 level1 lfo3'>Section 2.2, page 2-1: “This SCCS-ADD Green Book provides the top-level description of the architecture elements of space communications cross support.” Our ADD should provide the top-level description of the architecture elements of the OAIS-IF. Seems to me that “Top Level” includes the entire UML chart that Steve has developed. However, Steve made verbal reference to focusing on the “gray/green boxes”. The document that focuses on the abstraction layer should be the Archive Abstraction Layer Blue Book. Our counterpart to the <a href="https://public.ccsds.org/Pubs/521x0b2e1.pdf">MAL</a>. <o:p></o:p></li></ul><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>So there’s my notional Doc Tree, and how the ADD relates to it. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='color:#002060'> -=- Mike<o:p></o:p></span></p><p class=MsoNormal><span style='color:#002060'><o:p> </o:p></span></p><p class=MsoNormal>Mike Kearney<span style='color:#002060'><o:p></o:p></span></p><p class=MsoNormal><span style='color:#002060'>Huntsville, Alabama, USA <o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>