[Moims-dai] FW: DAI WG Green and Blue Book

[kearneysolutions at gmail.com]

FYI, the exchange with Peter Shames on the document tree topic.  

 

   -=- Mike

 

Mike Kearney

Huntsville, Alabama, USA 

 

From: david at giaretta.org <david at giaretta.org> 
Sent: Tuesday, October 11, 2022 8:06 AM
To: 'Shames, Peter M (US 312B)' <peter.m.shames at jpl.nasa.gov>; 'Hughes, J S (US 398B)' <john.s.hughes at jpl.nasa.gov>; kearneysolutions at gmail.com; 'John Garrett' <garrett at his.com>
Subject: RE: DAI WG Green and Blue Book

 

Hi Peter

 

This is very helpful.

The final call is Steve’s.

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! 

A “compendium” BB has its attractions in that we could add details for switchboard etc., to replace manual configurations, later on.

 

Cheers

 

..David

 

From: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov <mailto:peter.m.shames at jpl.nasa.gov> > 
Sent: 10 October 2022 22:56
To: 'david' <david at giaretta.org <mailto:david at giaretta.org> >; Hughes, J S (US 398B) <john.s.hughes at jpl.nasa.gov <mailto:john.s.hughes at jpl.nasa.gov> >; kearneysolutions at gmail.com <mailto:kearneysolutions at gmail.com> ; John Garrett <garrett at his.com <mailto:garrett at his.com> >
Subject: Re: DAI WG Green and Blue Book

 

Guys,

 

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.

 

Here is the document feedback I can give you:

1.	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.
2.	The Green Book is a good example of it’s breed too, which is, indeed, GB.  
3.	To underscore the distinction I am trying to draw in re the MB, look at Figure 2‑6 “Indication of functionality in adapters” 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.

 

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.

 

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.

 

Ok?

 

Thanks, Peter

 

From: Steve Hughes <john.s.hughes at jpl.nasa.gov <mailto:john.s.hughes at jpl.nasa.gov> >
Date: Tuesday, July 5, 2022 at 2:26 PM
To: Peter Shames <peter.m.shames at jpl.nasa.gov <mailto:peter.m.shames at jpl.nasa.gov> >
Cc: Mike Kearney <kearneysolutions at gmail.com <mailto:kearneysolutions at gmail.com> >, David Giaretta <david at giaretta.org <mailto:david at giaretta.org> >, John Garrett <garrett at his.com <mailto:garrett at his.com> >
Subject: RE: DAI WG Green and Blue Book

 

Hi Peter,

 

We went full circle. 

 

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. 

 

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.

 

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.

 

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.

 

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.

 

I hope this helps.

Thanks,

Steve

 

 

From: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov <mailto:peter.m.shames at jpl.nasa.gov> > 
Sent: Tuesday, July 5, 2022 3:32 PM
To: Hughes, J S (US 398B) <john.s.hughes at jpl.nasa.gov <mailto:john.s.hughes at jpl.nasa.gov> >
Cc: kearneysolutions at gmail.com <mailto:kearneysolutions at gmail.com> 
Subject: Re: DAI WG Green and Blue Book

 

Hi Steve,

 

Give me a little time to mull this over, ok?

 

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.

 

You said :  Write code => transform into JavaDoc => transform into UML  model(at least that’s how I understand the ordering)

 

Standard MBSE would do this: Create UML model => Transform UML into Java Doc => Transform UML into code

 

Did I get this wrong?  It’s inventive, but somewhat “backwards” in terms of how things usually work in the MBSE world.

 

Thanks, Peter

 

 

From: Steve Hughes <john.s.hughes at jpl.nasa.gov <mailto:john.s.hughes at jpl.nasa.gov> >
Date: Thursday, June 30, 2022 at 5:06 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov <mailto:peter.m.shames at jpl.nasa.gov> >
Cc: Mike Kearney <kearneysolutions at gmail.com <mailto:kearneysolutions at gmail.com> >
Subject: RE: DAI WG Green and Blue Book

 

Hi Peter,

 

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.

 

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.

 

Thanks,

Steve

 

 

From: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov <mailto:peter.m.shames at jpl.nasa.gov> > 
Sent: Wednesday, June 29, 2022 7:18 PM
To: Hughes, J S (US 398B) <john.s.hughes at jpl.nasa.gov <mailto:john.s.hughes at jpl.nasa.gov> >
Cc: kearneysolutions at gmail.com <mailto:kearneysolutions at gmail.com> 
Subject: Re: DAI WG Green and Blue Book

 

Hi Steve & Mike,

 

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.  

 

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.

 

Best regards, Peter

 

 

From: Steve Hughes <john.s.hughes at jpl.nasa.gov <mailto:john.s.hughes at jpl.nasa.gov> >
Date: Wednesday, June 29, 2022 at 3:13 PM
To: Peter Shames <peter.m.shames at jpl.nasa.gov <mailto:peter.m.shames at jpl.nasa.gov> >
Cc: Steve Hughes <john.s.hughes at jpl.nasa.gov <mailto:john.s.hughes at jpl.nasa.gov> >, Mike Kearney <kearneysolutions at gmail.com <mailto:kearneysolutions at gmail.com> >
Subject: FW: DAI WG Green and Blue Book

 

Hi Peter,

 

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.   

 

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).  

 

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.  

 

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?  

 

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.   

 

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.   

 

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.   

 

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.  

 

Thank you,

Steve

 

P.S. Mike gets the credit for drafting this note.

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-dai/attachments/20221011/4b34e0a4/attachment-0001.htm>