<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=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@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:811558410;
        mso-list-type:hybrid;
        mso-list-template-ids:1879502402 -145879698 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
        {mso-level-text:"%1\)";
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level2
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level3
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
@list l0:level4
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level5
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level6
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
@list l0:level7
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level8
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level9
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
@list l1
        {mso-list-id:989017688;
        mso-list-template-ids:-120920328;}
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'>FYI, the exchange with Peter Shames on the document tree topic.  <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> david@giaretta.org <david@giaretta.org> <br><b>Sent:</b> Tuesday, October 11, 2022 8:06 AM<br><b>To:</b> 'Shames, Peter M (US 312B)' <peter.m.shames@jpl.nasa.gov>; 'Hughes, J S (US 398B)' <john.s.hughes@jpl.nasa.gov>; kearneysolutions@gmail.com; 'John Garrett' <garrett@his.com><br><b>Subject:</b> RE: DAI WG Green and Blue Book<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span lang=EN-GB>Hi Peter<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>This is very helpful.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>The final call is Steve’s.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>My preference, given how long these things take, is to produce a BB which has the API with the JSON and REST and whatever else is needed to allow implementation. I think we are pretty close to having all the pieces needed. This would allow us to demonstrate something useful before we drop off our respective perches! <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>A </span>“compendium” BB has its attractions in that we could add details for switchboard etc., to replace manual configurations, later on.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Cheers<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>..David<span lang=EN-GB><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><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> Shames, Peter M (US 312B) <<a href="mailto:peter.m.shames@jpl.nasa.gov">peter.m.shames@jpl.nasa.gov</a>> <br><b>Sent:</b> 10 October 2022 22:56<br><b>To:</b> 'david' <<a href="mailto:david@giaretta.org">david@giaretta.org</a>>; Hughes, J S (US 398B) <<a href="mailto:john.s.hughes@jpl.nasa.gov">john.s.hughes@jpl.nasa.gov</a>>; <a href="mailto:kearneysolutions@gmail.com">kearneysolutions@gmail.com</a>; John Garrett <<a href="mailto:garrett@his.com">garrett@his.com</a>><br><b>Subject:</b> Re: DAI WG Green and Blue Book<o:p></o:p></p></div></div><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal>Guys,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I know that this response to you has been delayed.  Other stuff has continually been shoved on my plate, but that is a poor excuse.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Here is the document feedback I can give you:<o:p></o:p></p><ol style='margin-top:0in' start=1 type=1><li class=MsoListParagraph style='margin-left:0in;mso-list:l0 level1 lfo3'>The OAIS IF Architecture Description is a really well done example of an architecture description document.  As such it is a Magenta Book because it is not directly implementable for interoperability and cross support.  It is abstract interfaces and components.  To be a Blue Book it would need to specify actual protocols and data structures.  I suggest that you reformat this document accordingly and publish it with those changes.<o:p></o:p></li><li class=MsoListParagraph style='margin-left:0in;mso-list:l0 level1 lfo3'>The Green Book is a good example of it’s breed too, which is, indeed, GB.  <o:p></o:p></li><li class=MsoListParagraph style='margin-left:0in;mso-list:l0 level1 lfo3'>To underscore the distinction I am trying to draw in re the MB, look at <a name="_Toc106716104"></a><a name="_Ref80441467"><span style='mso-bookmark:_Toc106716104'>Figure 2‑6</span></a><span style='mso-bookmark:_Toc106716104'> “Indication of functionality in adapters</span>” in the GB.  Now imagine that you had actually formally defined the protocols on the red lines among the “User & Archive Generic Adapters”, the “Comm Infrastructure”, and the “Registry” and “Switchboard”, and that you had defined the behaviors and information models at the interfaces of all of these elements … or even a generic model and the means to specifically extend and specialize these in a concrete way.  That (or those) could/should be Blue Books.<o:p></o:p></li></ol><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>This last piece (or pieces if you parse the specific archive class adapters out from the generic framework) would be Blue Books.  As long as they meet the test of “directly implementable for interoperability and cross support” they will be Blue Books.  These are not.  To tie it to your question, asked months ago, any specific JSON or HTTP/REST protocol specs would be Blue Books (or should be).  Any formally defined information models should likewise be Blue Books.  You might consider making each of these separate BB or even a “compendium” BB where you add new chapters for new bindings if that seems workable.  That said, separate docs are probably more manageable.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>And I would strongly advise against tying this framework to MO/MAL.  That “answer to every maiden’s prayers” has taken 20 years to get going and it still has not lifted off.  Define something direct and to the point, not abstractions layered on abstractions.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Ok?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks, Peter<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:12.0pt;color:black'>From: </span></b><span style='font-size:12.0pt;color:black'>Steve Hughes <<a href="mailto:john.s.hughes@jpl.nasa.gov">john.s.hughes@jpl.nasa.gov</a>><br><b>Date: </b>Tuesday, July 5, 2022 at 2:26 PM<br><b>To: </b>Peter Shames <<a href="mailto:peter.m.shames@jpl.nasa.gov">peter.m.shames@jpl.nasa.gov</a>><br><b>Cc: </b>Mike Kearney <<a href="mailto:kearneysolutions@gmail.com">kearneysolutions@gmail.com</a>>, David Giaretta <<a href="mailto:david@giaretta.org">david@giaretta.org</a>>, John Garrett <<a href="mailto:garrett@his.com">garrett@his.com</a>><br><b>Subject: </b>RE: DAI WG Green and Blue Book<o:p></o:p></span></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>Hi Peter,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>We went full circle. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Using Protégé, we modeled the OAIS-Reference Model (OAIS-RM) Functional Entities, OAIS-RM Information Model (IM), and the proposed OAIS-Interoperability Framework (OAIS-IF). We exported the contents of the Protégé ontology to XMI/XML and loaded it into MagicDraw. MagicDraw was used to generate our initial UML. Most of our deliberation over the past two years has focused on the generated component, interaction, class, deployment, and interface diagrams. For the BB, we decided to standardize the interfaces. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Actually we have two UML models, David also has one using another design package. Many of his diagrams can be found in the green book.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>To test the interfaces, a JAVA prototype was written. First the OAIS IF Interface and OAIS-RM IM designs were imported into Netbeans. Client JAVA code was added for a GUI and associated routines to instantiate producer, consumer, and archive applications. We are using the prototype to test the adequacy of the OAIS IF Interfaces and the abstract classes.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>For the BB, we use NetBean capabilities to generate primarily the JAVADoc. However some NetBeans UML was also generated and included in the document. This approach was simple and depicts what was implemented exactly.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Changes that resulted from the implementation are being fed back into the original Protégé model as will changes from current and future reviews. That is as long as time and resources are available.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I hope this helps.<o:p></o:p></p><p class=MsoNormal>Thanks,<o:p></o:p></p><p class=MsoNormal>Steve<o:p></o:p></p><p class=MsoNormal><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> Shames, Peter M (US 312B) <<a href="mailto:peter.m.shames@jpl.nasa.gov">peter.m.shames@jpl.nasa.gov</a>> <br><b>Sent:</b> Tuesday, July 5, 2022 3:32 PM<br><b>To:</b> Hughes, J S (US 398B) <<a href="mailto:john.s.hughes@jpl.nasa.gov">john.s.hughes@jpl.nasa.gov</a>><br><b>Cc:</b> <a href="mailto:kearneysolutions@gmail.com">kearneysolutions@gmail.com</a><br><b>Subject:</b> Re: DAI WG Green and Blue Book<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Hi Steve,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Give me a little time to mull this over, ok?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>But I do have one immediate bit of feedback: the approach you seem to have taken is the exact inverse of how MBSE usually works.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>You said :  Write code => transform into JavaDoc => transform into UML  model(at least that’s how I understand the ordering)<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Standard MBSE would do this: Create UML model => Transform UML into Java Doc => Transform UML into code<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Did I get this wrong?  It’s inventive, but somewhat “backwards” in terms of how things usually work in the MBSE world.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks, Peter<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:12.0pt;color:black'>From: </span></b><span style='font-size:12.0pt;color:black'>Steve Hughes <<a href="mailto:john.s.hughes@jpl.nasa.gov">john.s.hughes@jpl.nasa.gov</a>><br><b>Date: </b>Thursday, June 30, 2022 at 5:06 AM<br><b>To: </b>Peter Shames <<a href="mailto:peter.m.shames@jpl.nasa.gov">peter.m.shames@jpl.nasa.gov</a>><br><b>Cc: </b>Mike Kearney <<a href="mailto:kearneysolutions@gmail.com">kearneysolutions@gmail.com</a>><br><b>Subject: </b>RE: DAI WG Green and Blue Book<o:p></o:p></span></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>Hi Peter,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I have a  prototype written in JAVA that demonstrates the proposed interoperability at a basic level. The prototype was written in NetBeans. The JavaDoc and most of the UML in the book was generated directly from the prototype.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>At some point in your review of the documentation, it might be useful if you and I had a telecom. I could start to answer questions and demonstrate the prototype.<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>Steve<o:p></o:p></p><p class=MsoNormal><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> Shames, Peter M (US 312B) <<a href="mailto:peter.m.shames@jpl.nasa.gov">peter.m.shames@jpl.nasa.gov</a>> <br><b>Sent:</b> Wednesday, June 29, 2022 7:18 PM<br><b>To:</b> Hughes, J S (US 398B) <<a href="mailto:john.s.hughes@jpl.nasa.gov">john.s.hughes@jpl.nasa.gov</a>><br><b>Cc:</b> <a href="mailto:kearneysolutions@gmail.com">kearneysolutions@gmail.com</a><br><b>Subject:</b> Re: DAI WG Green and Blue Book<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Hi Steve & Mike,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I just want to acknowledge receipt of this and confirm that I am willing to work with you to try and find a viable path forward.  I know that what you have chosen to tackle is not simple, and so I have no expectation that this proposal will be simple.  <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>As long as your intent is to actually define something that can be made interoperable I think we’ll find a path that works.  I’ll let you know more after I have a chance to examine what you have produced.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Best regards, Peter<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:12.0pt;color:black'>From: </span></b><span style='font-size:12.0pt;color:black'>Steve Hughes <<a href="mailto:john.s.hughes@jpl.nasa.gov">john.s.hughes@jpl.nasa.gov</a>><br><b>Date: </b>Wednesday, June 29, 2022 at 3:13 PM<br><b>To: </b>Peter Shames <<a href="mailto:peter.m.shames@jpl.nasa.gov">peter.m.shames@jpl.nasa.gov</a>><br><b>Cc: </b>Steve Hughes <<a href="mailto:john.s.hughes@jpl.nasa.gov">john.s.hughes@jpl.nasa.gov</a>>, Mike Kearney <<a href="mailto:kearneysolutions@gmail.com">kearneysolutions@gmail.com</a>><br><b>Subject: </b>FW: DAI WG Green and Blue Book<o:p></o:p></span></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>Hi Peter,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The DAI WG would like to get your input on our documents (and their colors) and the document tree in general.  We’d like to head off future problems (for example, lessons learned from SM&C history) and get your reading on our direction.  Attached are drafts for an overview Green Book, and an ADD Blue Book.   <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>We’re not expecting you to read our documents in detail.  We’d just like you to scan them and give us some guidance on whether we’ve got generally the right kind of content and CCSDS classification (Blue vs. Magenta).  <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>We have a green book which is almost certainly a green book.  Attached, it can provide you some background.  Figure 6-1 (pg 34)  is a document tree.  <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>We have an Architecture Description Document that started out as Magenta but has evolved into (we think) blue territory.  This is our main question:  Do we keep the current document, or do we need to split it into multiple documents?  In the latter case, what content goes where?  <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>As another discussion item, we recognized that there were issues in the past where it took multiple blue books to confer interoperability (like MAL, Bindings, etc.)  We think that your position in the past is that all blue book specifications needed to be interoperable should be in one blue book.  Can you confirm if that is a requirement, or do we have an option to break out multiple layers of our architecture (generic adapters, specific adapters) into separate books.  I’m sure you recognize that separate books for different (modular) layers would be easier to update.  But we recognize that it complicates things if users have to “assemble” an interoperable stack from multiple components, not to mention verifying interoperability with multiple prototypes.   <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>If you look at figure 4 in the ADD draft BB, you’ll see that in the Generic Adapters, we’ve identified JSON and HTTP/REST as the protocol and synchronization interfaces of the generic adapters.  But we believe there will be other options implemented by some organizations, and we may even standardize those other options as future appendices for this blue book, or as new separate blue books.  But by including JSON and HTTP/REST as the “default” configuration, we can achieve end-to-end interoperability in the basic blue book, if indeed that’s necessary.  Our question is… is this really necessary, or do we have the option to break them out in separate books.   <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Also, can you confirm if PICS-Proforma are required for all blue books?  If so, we would include it as an appendix in the BB, and while the basic info on the adapters would be mandatory, the JSON/HTTP/REST functions would be optional, or selectable between those protocols and some other protocols.  Basically, we haven’t done a PICS-Proforma before, and we’re fishing for whether we’re utilizing it correctly.   <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>So, that’s the nature of our document questions.   As we said, we’re just trying to get ahead of the game and avoid a rewrite of our work later in the game.   Any inputs from you are more than appreciated, especially on the (currently white) ADD Blue Book.  <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thank you,<o:p></o:p></p><p class=MsoNormal>Steve<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>P.S. Mike gets the credit for drafting this note.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>